摘要:之前測試頁面加載的時間都是在相應(yīng)的位置打,通過計算時間差來實現(xiàn)。見下圖不僅幫我們省去了繁瑣的手動打點的操作,而且提供了以前我們無法獲取到的數(shù)據(jù),比如和連接所需的時間。如果沒有發(fā)起請求,同上開始建立請求的時間。
原文鏈接
起因最近接觸到了一個性能優(yōu)化方面為我們提供精準(zhǔn)數(shù)據(jù)的工具,Navigation Timing,本想從網(wǎng)上獲取他更詳細(xì)的信息,但搜索到的內(nèi)容絕大部分都是國外的文章,遂決定寫一遍具體分析的文章。
之前測試頁面加載的時間都是在相應(yīng)的位置打Date.now(),通過計算時間差來實現(xiàn)。這樣的做法有很多弊端。
需要在許多地方添加額外的代碼
記錄的時間不準(zhǔn)確
測試完之后需要找到每一個地方注釋or刪除,容易落下且麻煩
W3C Web Performance Working Group 引入了 Navigation Timing API 幫我們自動,精準(zhǔn)的實現(xiàn)了性能測試的打點問題。
Navigation Timing API 用法用法很簡單,在頁面load完之后我們可以從performance.timing對象中拿到我們需要的所有數(shù)據(jù)。見下圖:
Navigation Timing不僅幫我們省去了繁瑣的手動打點的操作,而且提供了以前我們無法獲取到的數(shù)據(jù),比如DNS和TCP連接所需的時間。
里面提供的具體事件如下圖:
參數(shù)說明具體文字說明:
navigationStart
加載起始時間
redirectStart
重定向開始時間(如果發(fā)生了HTTP重定向,每次重定向都和當(dāng)前文檔同域的話,就返回開始重定向的fetchStart的值。其他情況,則返回0)
redirectEnd
重定向結(jié)束時間(如果發(fā)生了HTTP重定向,每次重定向都和當(dāng)前文檔同域的話,就返回最后一次重定向接受完數(shù)據(jù)的時間。其他情況則返回0)
fetchStart
瀏覽器發(fā)起資源請求時,如果有緩存,則返回讀取緩存的開始時間
domainLookupStart
查詢DNS的開始時間。如果請求沒有發(fā)起DNS請求,如keep-alive,緩存等,則返回fetchStart
domainLookupEnd
查詢DNS的結(jié)束時間。如果沒有發(fā)起DNS請求,同上
connectStart
開始建立TCP請求的時間。如果請求是keep-alive,緩存等,則返回domainLookupEnd
(secureConnectionStart)
如果在進(jìn)行TLS或SSL,則返回握手時間
connectEnd
完成TCP鏈接的時間。如果是keep-alive,緩存等,同connectStart
requestStart
發(fā)起請求的時間
responseStart
服務(wù)器開始響應(yīng)的時間
domLoading
從圖中看是開始渲染dom的時間,具體未知
domInteractive
未知
domContentLoadedEventStart
開始觸發(fā)DomContentLoadedEvent事件的時間
domContentLoadedEventEnd
DomContentLoadedEvent事件結(jié)束的時間
domComplete
從圖中看是dom渲染完成時間,具體未知
loadEventStart
觸發(fā)load的時間,如沒有則返回0
loadEventEnd
load事件執(zhí)行完的時間,如沒有則返回0
unloadEventStart
unload事件觸發(fā)的時間
unloadEventEnd
unload事件執(zhí)行完的時間
注,從domLoading開始往下的參數(shù)chrome官網(wǎng)并未給出具體英文解釋,只是猜測,如有錯誤,歡迎糾正。
附上官方鏈接
簡單用法這些參數(shù)已經(jīng)非常詳細(xì),也很精準(zhǔn),稍作處理就可以得出我們需要的一些關(guān)鍵數(shù)字,如:
DNS解析時間: domainLookupEnd - domainLookupStart
TCP建立連接時間: connectEnd - connectStart
白屏?xí)r間: responseStart - navigationStart
dom渲染完成時間: domContentLoadedEventEnd - navigationStart
頁面onload時間: loadEventEnd - navigationStart
demo如下:
let timing = performance.timing, start = timing.navigationStart, dnsTime = 0, tcpTime = 0, firstPaintTime = 0, domRenderTime = 0, loadTime = 0; dnsTime = timing.domainLookupEnd - timing.domainLookupStart; tcpTime = timing.connectEnd - timing.connectStart; firstPaintTime = timing.responseStart - start; domRenderTime = timing.domContentLoadedEventEnd - start; loadTime = timing.loadEventEnd - start; console.log("DNS解析時間:", dnsTime , " TCP建立時間:", tcpTime, " 首屏?xí)r間:", firstPaintTime, " dom渲染完成時間:", domRenderTime, " 頁面onload時間:", loadTime);
效果如下:
兼容性目前Navigation Timing已經(jīng)普及,絕大部分主流瀏覽器都已經(jīng)支持
那么,開始優(yōu)化你的app吧
3Fuyu
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/84064.html
摘要:性能時間線以一個統(tǒng)一的接口獲取由和所收集的性能數(shù)據(jù)。瀏覽器支持下表列舉了當(dāng)前主流瀏覽器對性能的支持,其中標(biāo)注星號的內(nèi)容并非來自于性能工作小組。 頁面的性能問題一直是產(chǎn)品開發(fā)過程中的重要一環(huán),很多公司也一直在使用各種方式監(jiān)控產(chǎn)品的頁面性能。從控制臺工具、Fiddler抓包工具,到使用DOMContentLoaded和document.onreadystatechange這種侵入式j(luò)ava...
摘要:概述最近在做一個上報相關(guān)的需求,該需求指定上班的內(nèi)容中包含頁面記載的事件請求花費的事件以及渲染所要完成的時間等。網(wǎng)頁導(dǎo)航的相關(guān)對象。瀏覽器內(nèi)存情況相關(guān)對象。 概述 最近在做一個上報相關(guān)的需求,該需求指定上班的內(nèi)容中包含頁面記載的事件、請求花費的事件、以及DOM渲染所要完成的時間等。 為此查閱了大量的文檔,收集了很多資料,所以趁熱打鐵,把自己所了解的記錄下來,方便以后查詢。 perf...
摘要:記錄使用遇到的問題本文中指的是。上線了以后拿到的首批數(shù)據(jù)中,后端時間計算出來竟然有負(fù)值,尤其在設(shè)備下,苦苦尋找原因,終于發(fā)現(xiàn)問題所在。如果事件沒有觸發(fā),那么該接口就返回文檔觸發(fā)事件結(jié)束后的時間。 記錄使用Performance API遇到的問題 本文中Performance API指的是Navigation Timing API。這并不是一篇Navigation Timing API的...
摘要:所以,關(guān)于優(yōu)化實戰(zhàn)我們主要分為兩部分加載渲染鏈路優(yōu)化和編程代碼優(yōu)化。加載渲染鏈路優(yōu)化從訪問到頁面呈現(xiàn),整個鏈路可以做優(yōu)化的思路。資源緩存這一節(jié)我們單獨介紹緩存,是的,利用好緩存可以解決很多問題,包括頁面加載和渲染的問題都能得到很好的優(yōu)化。 優(yōu)化實戰(zhàn) 本文屬于思否課堂VirtualDOM到AST玩轉(zhuǎn)前端性能原理解析與代碼實戰(zhàn)課程官方博客:fed123.com 我們已經(jīng)全面分析總結(jié)了評估頁...
閱讀 927·2021-11-16 11:45
閱讀 2133·2021-10-09 09:44
閱讀 1351·2019-08-30 14:03
閱讀 1136·2019-08-26 18:28
閱讀 3336·2019-08-26 13:50
閱讀 1722·2019-08-23 18:38
閱讀 3456·2019-08-23 18:22
閱讀 3601·2019-08-23 15:27