10分鐘徹底搞懂前端頁面性能監控
前言
前端頁面性能是一個非常核心的用戶體驗指標。本文介紹阿里UC 岳鷹全景監控平台如何設計一個通用、低侵入性、自動上報的頁面性能監控方案。主要採用的是Navigation Timing API以及sendBeacon等方法。
為什麼要監控頁面性能？
一個頁面性能差的話會大大影響用戶體驗。用戶打開頁面等待的太久，可能會直接關掉頁面，甚至就不再使用了，這種情況在移動端更加明顯，移動端用戶對頁面響應延遲容忍度很低。
雖然頁面性能很重要，但是在實際使用中，頁面性能差的情況並不少見。首先，在產品的迭代演進過程中，頁面性能可能會被忽略，性能隨著版本迭代而有所衰減；其次，性能優化是一項複雜而挑戰的事情，需要明確的優化方向和具體的優化手段才能快速落地取效。
所以我們需要一個性能監控系統，持續監控和預警頁面性能的狀況，並且在發現瓶頸的時候指導優化工作。
理解Navigation Timing API的性能指標
為了幫助開發者更好地衡量和改進前端頁面性能，W3C性能小組引入了Navigation Timing API ，實現了自動、精準的頁面性能打點；開發者可以通過window.performance 屬性獲取。
- performance.timing 接口（定義了從navigationStart 至loadEventEnd 的21 個只讀屬性）
- performance.navigation（定義了當前文檔的導航訊息，比如是重載還是向前向後等）
下圖是W3C第一版的Navigation Timing 的處理模型。從當前瀏覽器窗口卸載舊頁面開始，到新頁面加載完成，整個過程一共被切分為9 個小塊：提示卸載舊文檔、重定向/卸載、應用緩存、DNS 解析、TCP 握手、HTTP 請求處理、HTTP 響應處理、DOM 處理、文檔裝載完成。每個小塊的首尾、中間做事件分界，取Unix 時間戳，兩兩事件之間計算時間差，從而獲取中間過程的耗時（精確到毫秒級別）。
上圖是Level 1 的規範，2012 年底進入候選建議階段，至今仍在日常使用中；但是在W3C的議程上，它已經功成身退，讓位給了精度更高，功能更強大，層次更分明的Level 2（處理模型如下圖）。比如獨立劃分出來的Resource Timing，使得我們可以獲取具體資源的詳細耗時訊息。
指標解讀
採集頁面性能的關鍵指標
使用上面的指標，我們可以計算許多重要的指標，如首字節的時間，頁面加載時間，dns查找以及連接是否安全。我們把Navigation Timing API 提供的指標做下歸類，按照從上到下的時間流，右邊的時刻標記了每個指標從哪裡開始計算到哪裡截止，比如，跳轉時間redirect 由redirectEnd - redirectStart 計算得到，其他的類推。
確定統計起始點（navigationStart vs fetchStart ）
頁面性能統計的起始點時間，應該是用戶輸入網址回車後開始等待的時間。一個是通過navigationStart獲取，相當於在URL輸入欄回車或者頁面按F5刷新的時間點；另外一個是通過fetchStart，相當於瀏覽器準備好使用HTTP 請求獲取文檔的時間。
從開發者實際分析使用的場景，瀏覽器重定向、卸載頁面的耗時對頁面加載分析並無太大作用；通常建議使用fetchStart 作為統計起始點。
首字節
主文檔返回第一個字節的時間，是頁面加載性能比較重要的指標。對用戶來說一般無感知，對於開發者來說，則代表訪問網絡後端的整體響應耗時。
白屏時間
用戶看到頁面展示出現一個元素的時間。很多人認為白屏時間是頁面返回的首字節時間，但這樣其實並不精確，因為頭部資源還沒加載完畢，頁面也是白屏。
相對來說具備「白屏時間」統計意義的指標，可以取domLoading - fetchStart，此時頁面開始解析DOM樹，頁面渲染的第一個元素也會很快出現。
從W3C Navigation Timing Level 2 的方案設計，可以直接採用 ，此時頁面資源加載完成，即將進入渲染環節。
首屏時間
首屏時間是指頁面第一屏所有資源完整展示的時間。這是一個對用戶來說非常直接的體驗指標，但是對於前端卻是一個非常難以統計衡量的指標。
具備一定意義上的指標可以使用， ，甚至使用
，此時頁面DOM樹已經解析完成並且顯示內容。
以下給出統計頁面性能指標的方法。
lettimes={};lett=window.performance.timing;//優先使用navigation v2 https://www.w3.org/TR/navigation-timing-2/if(typeofwin.PerformanceNavigationTiming==='function'){try{varnt2Timing=performance.getEntriesByType('navigation')[0]if(nt2Timing){t=nt2Timing}}catch(err){}}//重定向時間times.redirectTime=t.redirectEnd-t.redirectStart;//dns查詢耗時times.dnsTime=t.domainLookupEnd-t.domainLookupStart;//TTFB讀取頁面第一個字節的時間times.ttfbTime=t.responseStart-t.navigationStart;//DNS緩存時間times.appcacheTime=t.domainLookupStart-t.fetchStart;//卸載頁面的時間times.unloadTime=t.unloadEventEnd-t.unloadEventStart;//tcp連接耗時times.tcpTime=t.connectEnd-t.connectStart;//request請求耗時times.reqTime=t.responseEnd-t.responseStart;//解析dom樹耗時times.analysisTime=t.domComplete-t.domInteractive;//白屏時間times.blankTime=(t.domInteractive||t.domLoading)-t.fetchStart;//domReadyTimetimes.domReadyTime=t.domContentLoadedEventEnd-t.fetchStart;SPA盛行之際
Navigation Timing API可以監控大部分前端頁面的性能。但隨著SPA模式的盛行，類似vue，reactjs等框架的普及，頁面內容渲染的時機被改變了，W3C標準無法完全滿足原來的監控意義。
幸運的是，目前W3C關於首屏統計已經進入了提議階段，以Chrome為首的瀏覽器正在打造更能代表用戶使用體驗的FP、FCP、FMP指標，並且逐步開放API。
注意點
- 通過window.performance.timing所獲的的頁面渲染所相關的數據，在SPA應用中改變了url但不刷新頁面的情況下是不會更新的。因此僅僅通過該api是無法獲得每一個子路由所對應的頁面渲染的時間。如果需要上報切換路由情況下每一個子頁面重新render的時間，需要自定義上報。
數據上報方式
測量好時間後，就需要將數據發送給服務端。頁面性能統計數據對丟失率要求比較低，且性能統計應該在盡量不影響主流程的邏輯和頁面性能的前提下進行。
使用的img標籤get請求
- 不存在AJAX跨域問題，可做跨源的請求
- 很古老的標籤，沒有瀏覽器兼容性問題
var i = new Image(); i.onload = i.onerror = i.onabort = function () { i = i.onload = i.onerror = i.onabort = null; } i.src = url;navigator.sendBeacon
大部分現代瀏覽器都支持navigator.sendBeacon方法。這個方法可以用來發送一些統計和診斷的小量數據，特別適合上報統計的場景。
- 數據可靠，瀏覽器關閉請求也照樣能發
- 異步執行，不會影響下一頁面的加載
- API使用簡單
window.addEventListener('unload', logData, false); function logData() { navigator.sendBeacon("/log", analyticsData); }最終方案
當瀏覽器支持sendBeacon方法，優先使用該方法，使用img方式降級上報。
岳鷹-WEB前端監控
經過1年左右時間的不斷打磨，阿里UC出品的岳鷹WEB前端監控已經對外開放，歡迎免費體驗試用。
技術交流、第一時間掌握產品動態，歡迎聯繫我們～
聯繫微信小助手(微信號effirst-assistant)
加入釘釘群討論(群號21964256)
參考
navigation-timing-2 https://www. w3.org/TR/navigation-ti ming-2/
Navigation API指南https:// s0developer0mozilla0org.icopy.site /en-US/docs/Web/Performance/Navigation_and_resource_timings