前端監控之效能與異常

作者：京東零售 李菲菲

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 後續

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