前端監控之性能與異常
作者:京東零售 李菲菲
1 前言
現有的大部分監控方案都是針對服務端的,而針對前端的監控很少,諸如線上頁面的白屏時間是多少、靜態資源的加載情況如何、接口請求耗時好久、什麼時候掛掉了、為什麼掛掉,這些都不清楚。
同時,在產品推廣過程中,經常需要統計頁面的使用情況及用户行為,從而可以從運營和產品的角度去了解用户羣體,進而迭代升級產品,使其更加貼近用户,為業務的擴展提供更多可能性。
因而,我們需要一個前端的頁面監控系統,持續監控和預警頁面性能的狀況,並且在發現瓶頸時用於指導優化工作。
2 前端監控目標
前端監控主要包含兩大塊:性能監控及異常監控
- 保證穩定性(異常監控)
錯誤監控包括 JavaScript 代碼錯誤,Promsie 錯誤,接口(XHR,fetch)錯誤,資源加載錯誤(script,link等)等,這些錯誤大多會導致頁面功能異常甚至白屏。 - 提升用户體驗(性能監控)
性能監控包括頁面的加載時間,接口響應時間等,側面反應了用户體驗的好壞。
3 性能監控
3.1 簡單描述頁面加載
簡單看一下,從輸入url到頁面加載完成的過程如下:
首先需要通過 DNS(域名解析系統)將 URL 解析為對應的 IP 地址,然後與這個 IP 地址確定的那台服務器建立起 TCP 網絡連接,隨後我們向服務端拋出 HTTP 請求,服務端處理完我們的請求之後,把目標數據放在 HTTP 響應裏返回給客户端,拿到響應數據的瀏覽器就可以開始走一個渲染的流程。渲染完畢,頁面便呈現給了用户。
我們可以將這個過程分為如下的過程片段:
- DNS 解析
- TCP 連接
- HTTP 請求拋出
- 服務端處理請求,HTTP 響應返回
- 瀏覽器拿到響應數據,解析響應內容,把解析的結果展示給用户
3.2 從開發者角度,看頁面加載各階段
從輸入url到用户可以使用頁面的全過程時間統計,會返回一個PerformanceTiming對象,單位均為毫秒。
關於performace,已經在《從前端角度淺談性能》中進行過介紹,,下面再強調一下:
各階段的性能耗時可以通過API:window.performance來獲取,對應的具體方法有:performance.timing、performance.getEntriesByType(‘resource’)、performance.navigation等。
如上,開發者可以通過performance中各階段的時間戳,分別獲取到 頁面各階段的性能指標,具體的個靜態資源的加載耗時、及 頁面是否重定向和重定向耗時。
按觸發順序排列所有屬性:
- navigationStart:在同一個瀏覽器上下文中,前一個網頁(與當前頁面不一定同域)unload 的時間戳,如果無前一個網頁 unload ,則與 fetchStart 值相等
- redirectStart:第一個 HTTP 重定向發生時的時間。有跳轉且是同域名內的重定向才算,否則值為 0
- unloadEventStart:前一個網頁(與當前頁面同域)unload 的時間戳,如果無前一個網頁 unload 或者前一個網頁與當前頁面不同域,則值為 0
- redirectEnd:最後一個 HTTP 重定向完成時的時間。有跳轉且是同域名內的重定向才算,否則值為 0
- unloadEventEnd:和 unloadEventStart 相對應,返回前一個網頁 unload 事件綁定的回調函數執行完畢的時間戳
- fetchStart:瀏覽器準備好使用 HTTP 請求抓取文檔的時間,這發生在檢查本地緩存之前
- domainLookupStart:DNS 域名查詢開始的時間,如果使用了本地緩存(即無 DNS 查詢)或持久連接,則與 fetchStart 值相等
- domainLookupEnd:DNS 域名查詢完成的時間,如果使用了本地緩存(即無 DNS 查詢)或持久連接,則與 fetchStart 值相等
- connectStart:HTTP(TCP) 開始建立連接的時間,如果是持久連接,則與 fetchStart 值相等,如果在傳輸層發生了錯誤且重新建立連接,則這裏顯示的是新建立的連接開始的時間
- secureConnectionStart:HTTPS 連接開始的時間,如果不是安全連接,則值為 0
- connectEnd:HTTP(TCP) 完成建立連接的時間(完成握手),如果是持久連接,則與 fetchStart 值相等,如果在傳輸層發生了錯誤且重新建立連接,則這裏顯示的是新建立的連接完成的時間
- requestStart:HTTP 請求讀取真實文檔開始的時間(完成建立連接),包括從本地讀取緩存,連接錯誤重連時,這裏顯示的也是新建立連接的時間
- responseStart:HTTP 開始接收響應的時間(獲取到第一個字節),包括從本地讀取緩存
- responseEnd:HTTP 響應全部接收完成的時間(獲取到最後一個字節),包括從本地讀取緩存
- domLoading:開始解析渲染 DOM 樹的時間,此時 Document.readyState 變為 loading,並將拋出 readystatechange 相關事件
- domInteractive:完成解析 DOM 樹的時間,Document.readyState 變為 interactive,並將拋出 readystatechange 相關事件
- domContentLoadedEventStart:DOM 解析完成後,網頁內資源加載開始的時間,文檔發生 DOMContentLoaded事件的時間
- domContentLoadedEventEnd:DOM 解析完成後,網頁內資源加載完成的時間(如 JS 腳本加載執行完畢),文檔的DOMContentLoaded 事件的結束時間
- domComplete:DOM 樹解析完成,且資源也準備就緒的時間,Document.readyState 變為 complete,並將拋出 readystatechange 相關事件
- loadEventStart:load 事件發送給文檔,也即 load 回調函數開始執行的時間,如果沒有綁定 load 事件,值為 0
- loadEventEnd:load 事件的回調函數執行完畢的時間,如果沒有綁定 load 事件,值為 0
3.3 各階段性能的計算(自定義)
1. `const { timing, navigation } = window.performance`
1. `const loadPageInfo = {};`
1. ``
1. `// 頁面加載類型,區分第一次load還是reload, 0初次加載、1重加載`
1. `loadPageInfo.loadType = navigation.type;`
1. ``
1. `// 頁面加載完成的時間 - 幾乎代表了用户等待頁面白屏的時間`
1. `loadPageInfo.loadPage = timing.loadEventEnd - timing.navigationStart;`
1. ``
1. `// 重定向的時間`
1. `loadPageInfo.redirect = timing.redirectEnd - timing.redirectStart;`
1. ``
1. `// 卸載頁面的時間`
1. `loadPageInfo.unloadEvent = timing.unloadEventEnd - timing.unloadEventStart;`
1. ``
1. `// 查詢 DNS 本地緩存的時間`
1. `loadPageInfo.appCache = timing.domainLookupStart - timing.fetchStart;`
1. ``
1. `// 【重要】DNS 查詢時間`
1. `// 頁面內是不是使用了太多不同的域名,導致域名查詢的時間太長?推薦 DNS 預加載。`
1. `// 可使用 HTML5 Prefetch 預查詢 DNS`
1. `loadPageInfo.lookupDomain = timing.domainLookupEnd - timing.domainLookupStart;`
1. ``
1. `// HTTP(TCP)建立連接完成握手的時間`
1. `loadPageInfo.connect = timing.connectEnd - timing.connectStart;`
1. ``
1. `// 【重要】HTTP請求及獲取 文檔內容的時間`
1. `loadPageInfo.request = timing.responseEnd - timing.responseStart;`
1. ``
1. `// 【重要】前一個頁面 unload 到 HTTP獲取到 頁面第一個字節的時間`
1. `// 【原因】這可以理解為用户拿到你的資源佔用的時間,推薦 加異地機房,加 CDN 處理,加寬帶,加 CPU 運算速度`
1. `// TTFB 即 Time To First Byte`
1. `loadPageInfo.ttfb = timing.responseStart - timing.navigationStart;`
1. ``
1. `// 解析 DOM 樹結構的時間`
1. `loadPageInfo.domReady = timing.domComplete - timing.responseEnd;`
1. ``
1. `// 【重要】執行 onload 回調函數的時間`
1. `// 【原因】是否太多不必要的操作都放在 onload 回調函數裏執行了,推薦 延遲加載、按需加載的策略`
1. `loadPageInfo.loadEvent = timing.loadEventEnd - timing.loadE`
4 異常監控
前端需要監控的錯誤主要有兩類:
- Javascript錯誤(js錯誤、promise錯誤)
- 監聽error錯誤(資源加載錯誤)
4.1 console.error
1. `// 重寫console.error,可以捕獲更全面的報錯信息`
1. `var oldError = console.error;`
1. ``
1. ``
1. `console.error = function(tempErrorMsg){`
1. `var errorMsg = ( arguments[0] && arguments[0].message ) || tempErrorMsg;`
1. `var lineNumber = 0;`
1. `var columnNumber = 0;`
1. `var errorStack = arguments[0] && arguments[0].stack;`
1. ``
1. ``
1. `if( !errorStack ){`
1. `saveJSError( 'console_error', errorMsg, '', lineNumber, columnNumber, 'CustomizeError: ' + errorMsg );`
1. `}else{`
1. `saveJSError( 'console_error', errorMsg, '', lineNumber, columnNumber, errorStack );`
1. `}`
1. ``
1. ``
1. `return oldError.apply( console, arguments );`
4.2 error事件
通過對error事件的監聽,可以捕捉到 js語法 及 資源加載 的錯誤。根據 event.target.src / href 來判斷是否為資源加載錯誤。
1. `window.addEventListener( 'error', function(e){`
1. `var errorMsg = e.error && e.error.message,`
1. `errorStack = e.error && e.error.stack,`
1. `pageUrl = e.filename,`
1. `lineNumber = e.lineno,`
1. `columnNumber = e.colno;`
1. ``
1. ``
1. `saveJSError( 'on_error', errorMsg, pageUrl, lineNumber, columnNumber, errorStack );`
1. `} );`
4.3 Promise
`// 捕獲未處理的Promise錯誤`
`window.onunhandledrejection = function(e){`
`var errorMsg = '';`
`var errorStack = '';`
`if( typeof e.reason === 'object' ){`
`errorMsg = e.reason.message;`
`errorStack = e.reason.stack;`
`}else{`
`errorMsg = e.reason;`
`errorStack = '';`
`}`
`saveJSError( 'on_error', errorMsg, '', 0, 0, 'UncaughtInPromiseError: ' + errorStack );`
`}`
5 總結
以上,通過簡單的js代碼,即可實現對頁面性能與異常的監控與數據上報,後續還需要相應具體的平台彙總,及相應的業務所需數據(如PV、UV等)的計算,才能真正實現對產品的頁面數據呈現,用於業務擴展及宣導。
6 後續
上述代碼,實現了對頁面性能及異常的監控,但其實前端的監控還包括了請求接口的監控與埋點的實現,後續將陸續推出,敬請期待。
- 應用健康度隱患刨析解決系列之數據庫時區設置
- 對於Vue3和Ts的心得和思考
- 一文詳解擴散模型:DDPM
- zookeeper的Leader選舉源碼解析
- 一文帶你搞懂如何優化慢SQL
- 京東金融Android瘦身探索與實踐
- 微前端框架single-spa子應用加載解析
- cookie時效無限延長方案
- 聊聊前端性能指標那些事兒
- Spring竟然可以創建“重複”名稱的bean?—一次項目中存在多個bean名稱重複問題的排查
- 京東金融Android瘦身探索與實踐
- Spring源碼核心剖析
- 深入淺出RPC服務 | 不同層的網絡協議
- 安全測試之探索windows遊戲掃雷
- 關於數據庫分庫分表的一點想法
- 對於Vue3和Ts的心得和思考
- Bitmap、RoaringBitmap原理分析
- 京東小程序CI工具實踐
- 測試用例設計指南
- 當你對 redis 説你中意的女孩是 Mia