作者：梁定安，騰訊織雲負責人，目前就職于騰訊社交網絡營運部，開放運維聯盟委員，騰訊雲布道師，複旦大學客座講師。
如今移動裝置性能越來越好，移動浏覽器對 HTML5(以下簡稱H5)的支援越來越完善。同時H5頁面隻需一次開發即可跨Android、IOS雙平台釋出、快速疊代、無需稽核。是以很多移動端産品都選擇H5實作。但H5應用每次請求頁面，都需要重新加載和渲染，先天性能、流程度沒有原生app好，卡慢現象出現更多。有時會收到到使用者回報和投訴：
使用者A：我的xx頁面打開太慢了；
使用者B: 登陸成功後清單顯示不全，上面顯示讀取内容失敗；
使用者C: 經常提示動态讀取失敗，這樣實在不友善，希望盡快改進。
面對使用者的回報，産品和開發也感到困惑：究竟有多慢？哪個步驟慢？是個别還是大範圍受影響？失敗的傳回碼是多少？是不是營運商劫持？能讓使用者配合用fillder抓個包麼？如何優化？優化的效果怎麼衡量？
為了便捷的衡量H5頁面的速度、品質，高效定位問題，給使用者提供更優質的服務。我們建設了自己的H5前端監控——天網雲ilook。
天網雲 ilook (以下簡稱 ilook )是天網監控體系中的一部分，專注于使用者端 H5監控，主要分3部分：
1. 測速系統
通過了解頁面響應時間分布情況優化應用，從白屏時間、首屏時間、網頁加載時間、資源加載時間和整頁完成時間角度展示使用者響應時間分布情況，通過浏覽器類型、裝置以及地理分布等多元度資料進行對比分析。提供端到端的可視化、快速定位緩慢原因及受影響的使用者詳情。
2. 傳回碼系統
在最接近使用者的場景，監控前端頁面http請求的成功率和延時，從時間、平台、網絡環境、地域等次元詳細分析，快速定位請求失敗和耗時長的具體環境，優化應用。
3. 診斷系統
診斷系統提供便捷的移動端使用者環境資訊搜集解決方案。下發一個 url，使用者打開後喚起手機 QQ，授權收集上報後，擷取使用者的裝置資訊、網絡資訊、使用者的出口 ip 和 localdns，同時可自定義 http 撥測規則。資料上報至背景，系統自動分析，給出診斷報告。
下面，我先介紹測速與傳回碼系統是如何實作的， 診斷系統在下次做單獨介紹。
1. 測速原理
我們一直在使用各種方式監控産品的頁面性能。從控制台、 Fiddler 抓包，到使用 DOMContentLoaded 和 document.onreadystatechange 這種侵入式javascript代碼方式來檢測 DOM 事件發生和結束的時間，再到使用第三方工具如某某助手等通過在不同的浏覽器環境和地域進行測試來尋求優化建議等等，這些方式不僅麻煩，而且測量的名額比較單一。好在W3C Web 性能工作小組與各浏覽器廠商都已認識到性能對于 web 開發的重要性，為了解決目前性能測試的困難，W3C 推出了一套性能 API 标準，各種浏覽器對這套标準的支援也逐漸成熟。
performance.timing 就是這套 API 提供的性能資料，它精确的告訴我們當通路一個網站頁面時目前網頁每個處理階段的精确時間( timestamp )，具體屬性值如下：
(每個屬性的詳細說明，可以在這裡了解https://www.w3.org/TR/navigation-timing/)
有了這些屬性的耗時資料，我們可以通過簡單計算擷取常用的一些頁面性能參數：
DNS 查詢耗時 ：domainLookupEnd - domainLookupStart
TCP 連結耗時 ：connectEnd - connectStart
request 請求耗時 ：responseEnd - responseStart
解析 dom 樹耗時 ： domComplete - domInteractive
白屏時間 ：responseStart - navigationStart
domready 時間 ：domContentLoadedEventEnd - navigationStart
onload 時間 ：loadEventEnd – navigationStart
1. 資料上報
怎麼擷取這些屬性資料呢？我們寫一個段簡單的 js (僅測試)試試：
調用後得到的上報結果如下：
我們約定每個名額為一個測速點，按順序用數字代替。然後，在前端頁面裡收集 performance.timing 以及業務自定義測速點耗時資料上報。
例如：
http://report.qq.com/report.cgi?appid=10012&speedparams=1%3D218%262%3D1115%26flag1%3D1486%26flag2%3D1%26flag3%3D3&apn=wifi&platform=android&rate=1
urldecode 後友善閱讀：
http://report.qq.com/report.cgi?appid=10012&speedparams=1=218&2=1115&flag1=1486&flag2=1&flag3=3&apn=wifi&platform=android&rate=1
flag1，flag2，flag3是系統自動配置設定的 id， 其中 flag1，flag2 用于辨別域名；flag3用于标示頁面。
Speedparams 的值 1，2代表測速點， 1，2的值為測試點耗時。
2. 資料統計
資料統計是基于我們二次開發的哈勃 jstorm 架構，進行實時 ETL 處理，分析計算頁面測速點的耗費時間、使用者分布。
4. 前端展示
常用的天趨勢對比：
還可以有很多展現，比如慢使用者畫像：
計算測速點延時正太分布：
點選測速點，可以從時間、平台、營運商、APN、省份等次元幫助分析使用者通路H5頁面的速度以及使用者分布。但是，這裡還是看單個測速點。怎樣更直覺的了解頁面性能損耗呢？我們想到常用的 chrome浏覽器的 developer tools 裡面的網絡 timing 圖：
從 timing 圖中可以看出，單個請求，每一個步驟耗時情況。那個步驟耗時最多，也非常清晰。再來看優化後實作的效果，這是最近7天的 timing 圖：
點選檢視明細，下圖的體驗是不是更加友好？
5.應用執行個體
有使用者回報某頁面響應慢，通過檢視測速資料，定位到是 js 執行時間引起。優化後，執行時間下降顯著：
前端頁面中上報每次請求的傳回碼(包括 http 協定傳回碼和業務傳回碼)和延時，背景給出各個緯度接口請求的成功率和耗時及使用者分布資料。
1.資料采集
在頁面中每次後端的 http 請求埋點，記錄、上報請求的傳回碼以及耗時資料。例如：H5頁面調用 test.qq.com/ cgi-bin/coupon_coin 這個接口，耗時(time=1214)ms,傳回碼(code=0), 傳回成功(type=1), 抽樣率為1(rate=1)
http://report.qq.com/code.cgi?time=1214&code=0&type=1&cgi=cgi-bin%2Fcoupon_coin&domain=test.qq.com&rate=1&uin=12345678&appid=10001
2.資料統計
資料統計也是基于我們二次開發的哈勃jstorm架構，進行實時ETL處理，最終根據地域、網絡類型、裝置等次元統計入庫成結果表。
3. 資料展現
提供多元度，靈活對比查詢，友善定位問題。
4.應用執行個體
某條接口成功率在98%左右，主要的錯誤碼為參數錯誤。根據該錯誤碼定位到送出請求的時候參數檢查存在問題，可能會送出空參數。修改釋出後，成功率保持在99.9%以上。
H5 監控作為業務品質的重要一環，意義重大。問題定位，性能優化都需要基于上報的資料進行。這裡總結了一下我們在前端監控的一些嘗試，怎樣讓監控系統更高效的定位問題，是我們一直在思考解決的問題。歡迎各位有好的想法一起交流探讨。