前端監控之性能與異常

作者：京東零售 李菲菲

1 前言

現有的大部分監控方案都是針對服務端的，而針對前端的監控很少，諸如線上頁面的白屏時間是多少、靜態資源的加載情況如何、接口請求耗時好久、什麼時候掛掉了、為什麼掛掉，這些都不清楚。

同時，在產品推廣過程中，經常需要統計頁面的使用情況及用户行為，從而可以從運營和產品的角度去了解用户羣體，進而迭代升級產品，使其更加貼近用户，為業務的擴展提供更多可能性。

因而，我們需要一個前端的頁面監控系統，持續監控和預警頁面性能的狀況，並且在發現瓶頸時用於指導優化工作。

2 前端監控目標

前端監控主要包含兩大塊：性能監控及異常監控

1. 保證穩定性（異常監控）
   錯誤監控包括 JavaScript 代碼錯誤，Promsie 錯誤，接口（XHR，fetch）錯誤，資源加載錯誤（script，link等）等，這些錯誤大多會導致頁面功能異常甚至白屏。
2. 提升用户體驗（性能監控）
   性能監控包括頁面的加載時間，接口響應時間等，側面反應了用户體驗的好壞。

3 性能監控

3.1 簡單描述頁面加載

簡單看一下，從輸入url到頁面加載完成的過程如下：

首先需要通過 DNS（域名解析系統）將 URL 解析為對應的 IP 地址，然後與這個 IP 地址確定的那台服務器建立起 TCP 網絡連接，隨後我們向服務端拋出 HTTP 請求，服務端處理完我們的請求之後，把目標數據放在 HTTP 響應裏返回給客户端，拿到響應數據的瀏覽器就可以開始走一個渲染的流程。渲染完畢，頁面便呈現給了用户。

我們可以將這個過程分為如下的過程片段：

1. DNS 解析
2. TCP 連接
3. HTTP 請求拋出
4. 服務端處理請求，HTTP 響應返回
5. 瀏覽器拿到響應數據，解析響應內容，把解析的結果展示給用户

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 異常監控

前端需要監控的錯誤主要有兩類：

1. Javascript錯誤（js錯誤、promise錯誤）
2. 監聽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 後續

上述代碼，實現了對頁面性能及異常的監控，但其實前端的監控還包括了請求接口的監控與埋點的實現，後續將陸續推出，敬請期待。