初探performance.timing API

本文轉載自查看原文 2013-11-15 11:18 2869 html5/ 原生javascript/ performance.timing/ Navigation Timing

瀏覽器新提供的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);