初探performance.timing API

浏览器新提供的performance接口精确的告诉我们当访问一个网站页面时当前网页每个处理阶段的精确时间(timestamp)，以方便我们进行前端分析。

它是浏览器的直接实现，比之前在网页中用js设置Date.time或者cookie来分析网页时间上要精确很多。

以下是w3c提供的performance.timing各阶段api图

暂时的缺点：

Navigation Timing stops at the window.onload event

现代的网站很多是在onload之后再发触发更多的异步请求，而navigation Timing统计却只在window.onload之后就不统计了。

为什么不在所有的网络请求完成后统计timing呢？

因为要考虑到有些网页有轮询或者长链接的情况。所以情况就复杂了，w3c还在草案阶段。如果你够牛想出好的解决方案，也可以直接发邮件到w3c去，贡献你的一份力量。

为方便查看统计值，自己写了一个简单的统计表插件

performanceTracer

performance API 耗时统计

统计点：

readyStart = timing.fetchStart - timing.navigationStart;
redirectTime = timing.redirectEnd  - timing.redirectStart;
appcacheTime = timing.domainLookupStart  - timing.fetchStart;
unloadEventTime = timing.unloadEventEnd - timing.unloadEventStart;
lookupDomainTime = timing.domainLookupEnd - timing.domainLookupStart;
connectTime = timing.connectEnd - timing.connectStart;
requestTime = timing.responseEnd - timing.requestStart;
initDomTreeTime = timing.domInteractive - timing.responseEnd;
domReadyTime = timing.domComplete - timing.domInteractive; //过早获取时 domComplete有时会是0
loadEventTime = timing.loadEventEnd - timing.loadEventStart;
loadTime = timing.loadEventEnd - timing.navigationStart;//过早获取时 loadEventEnd有时会是0

结果：

console.log('准备新页面时间耗时: ' + readyStart);
console.log('redirect 重定向耗时: ' + redirectTime);
console.log('Appcache 耗时: ' + appcacheTime);
console.log('unload 前文档耗时: ' + unloadEventTime);
console.log('DNS 查询耗时: ' + lookupDomainTime);
console.log('TCP连接耗时: ' + connectTime);
console.log('request请求耗时: ' + requestTime);
console.log('请求完毕至DOM加载: ' + initDomTreeTime);
console.log('解释dom树耗时: ' + domReadyTime);
console.log('load事件耗时: ' + loadEventTime);
console.log('从开始至load总耗时: ' + loadTime);