什么是前端監控？
它指的是通過一定的手段來獲取用戶行為以及跟蹤產品在用戶端的使用情況，並以監控數據為基礎，為產品優化指明方向，為用戶提供更加精確、完善的服務。
如果這篇文章有幫助到你，❤️關注+點贊❤️鼓勵一下作者，文章公眾號首發，關注 前端南玖 第一時間獲取最新的文章～
前端監控
一般來講一個成熟的產品，運營與產品團隊需要關注用戶在產品內的行為記錄，通過用戶的行為記錄來優化產品，研發與測試團隊則需要關注產品的性能以及異常，確保產品的性能體驗以及安全迭代。
所以前端監控一般也分為三大類：
數據監控（監控用戶行為）
- PV/UV: PV(page view)：即頁面瀏覽量或點擊量；UV：指訪問某個站點或點擊某條新聞的不同 IP 地址的人數
- 用戶在每一個頁面的停留時間
- 用戶通過什么入口來訪問該網頁
- 用戶在相應的頁面中觸發的行為，等...
統計這些數據是有意義的，比如我們知道了用戶來源的渠道，可以促進產品的推廣，知道用戶在每一個頁面停留的時間，可以針對停留較長的頁面，增加廣告推送等等。
性能監控（監控頁面性能）
- 不同用戶，不同機型和不同系統下的首屏加載時間
- 白屏時間
- http 等請求的響應時間
- 靜態資源整體下載時間
- 頁面渲染時間
- 頁面交互動畫完成時間，等...
這些性能監控的結果，可以展示前端性能的好壞，根據性能監測的結果可以進一步的去優化前端性能，盡可能的提高用戶體驗。
異常監控（監控產品、系統異常）
及時的上報異常情況，可以避免線上故障的發上。雖然大部分異常可以通過 try catch 的方式捕獲，但是比如內存泄漏以及其他偶現的異常難以捕獲。常見的需要監控的異常包括：
- Javascript 的異常監控
- 樣式丟失的異常監控
埋點上報
OK，上面我們說到了前端監控的三個分類，了解了一個產品需要監控哪些內容以及為什么需要監控這些內容，那么我們應該怎么實現前端監控呢？
實現前端監控，第一步肯定是將我們要監控的事項（數據）給收集起來，再提交給后台進行入庫，最后再給數據分析組進行數據分析，最后處理好的數據再同步給運營或者是產品。數據收集的豐富性和准確性會直接影響到我們做前端監控的質量，因為我們會以此為基礎，為產品的未來發展指引方向。
現在常見的埋點上報方法有三種：手動埋點、可視化埋點、無埋點
手動埋點
手動埋點，也叫代碼埋點，即純手動寫代碼，調用埋點 SDK 的函數，在需要埋點的業務邏輯功能位置調用接口，上報埋點數據，像[友盟]、[百度統計]等第三方數據統計服務商大都采用這種方案。手動埋點讓使用者可以方便地設置自定義屬性、自定義事件；所以當你需要深入下鑽，並精細化自定義分析時，比較適合使用手動埋點。
手動埋點的缺陷就是，項目工程量大，需要埋點的位置太多，而且需要產品開發運營之間相互反復溝通，容易出現手動差錯，如果錯誤，重新埋點的成本也很高。
可視化埋點
通過可視化交互的手段，代替上述的代碼埋點。將業務代碼和埋點代碼分離，提供一個可視化交互的頁面，輸入為業務代碼，通過這個可視化系統，可以在業務代碼中自定義的增加埋點事件等等，最后輸出的代碼耦合了業務代碼和埋點代碼。
可視化埋點的缺陷就是可以埋點的控件有限，不能手動定制。
無埋點
無埋點則是前端自動采集全部事件，上報埋點數據，由后端來過濾和計算出有用的數據。優點是前端只要一次加載埋點腳本，缺點是流量和采集的數據過於龐大，服務器性能壓力山大。
為什么都用GIF來做埋點？
發現過程
首先說一下我是怎么發現的，前一段時間，產品提了個需求，說我們現在的書籍曝光上報規范並不是他們想要的數據，並且以后所有頁面的書籍上報都統一成最新規范。
曝光規范：
- 書籍出現在可視區並停留1秒，算作有效曝光
- 書籍不能重復曝光，假如它一直在可視區滾動時只能上報一次
- 當它移出可視區后再回到可視區，再按第一點進行曝光
OK，既然要所有頁面統一，那就只能封裝成通用庫來使用了，這里實現邏輯就不貼了，想看的私聊我發你，主要的難點就是停留時長計算，以及曝光標記。
const exposeReportClass = new exposeReport({
scrollDom: "", // 滾動容器，建議指定一個滾動容器，不傳默認為window
watchDom: ".bookitem", // 監聽的dom,建議使用class類，標簽也支持
time: 1000 // 停留有效時長ms
});
// 提供兩個上報方法
exposeReportClass.didReport(()=>{
// 手動上報
//callback
})
exposeReportClass.scrollReport(()=>{
// 滾動動上報
//callback
})
//
具體業務邏輯之需要放在對應的callback里面，而上報邏輯開發者無需考慮，因為我底層已經統一處理好了。
然后我再測試的時候就發現，上報發的請求居然是通過圖片發起的，並不是我們認為的接口上報。
然后我去查了下資料，發現很多大廠的上報都是這么干的！
使用GIF上報的原因
向服務器端上報數據，可以通過請求接口，請求普通文件，或者請求圖片資源的方式進行。只要能上報數據，無論是請求GIF文件還是請求js文件或者是調用頁面接口，服務器端其實並不關心具體的上報方式。那為什么所有系統都統一使用了請求GIF圖片的方式上報數據呢？
- 防止跨域
一般而言，打點域名都不是當前域名，所以所有的接口請求都會構成跨域。而跨域請求很容易出現由於配置不當被瀏覽器攔截並報錯，這是不能接受的。但圖片的src屬性並不會跨域，並且同樣可以發起請求。（排除接口上報）
- 防止阻塞頁面加載，影響用戶體驗
通常，創建資源節點后只有將對象注入到瀏覽器DOM樹后，瀏覽器才會實際發送資源請求。反復操作DOM不僅會引發性能問題，而且載入js/css資源還會阻塞頁面渲染，影響用戶體驗。
但是圖片請求例外。構造圖片打點不僅不用插入DOM，只要在js中new出Image對象就能發起請求，而且還沒有阻塞問題，在沒有js的瀏覽器環境中也能通過img標簽正常打點，這是其他類型的資源請求所做不到的。（排除文件方式）
- 相比PNG/JPG，GIF的體積最小
最小的BMP文件需要74個字節，PNG需要67個字節，而合法的GIF，只需要43個字節。
同樣的響應，GIF可以比BMP節約41%的流量，比PNG節約35%的流量。
並且大多采用的是1*1像素的透明GIF來上報
1x1像素是最小的合法圖片。而且，因為是通過圖片打點，所以圖片最好是透明的，這樣一來不會影響頁面本身展示效果，二者表示圖片透明只要使用一個二進制位標記圖片是透明色即可，不用存儲色彩空間數據，可以節約體積。
推薦閱讀
- 介紹回流與重繪（Reflow & Repaint），以及如何進行優化?
- Promise、Generator、Async有什么區別？
- 【Vue源碼學習】依賴收集
- 【Vue源碼學習】響應式原理探秘
- JS定時器執行不可靠的原因及解決方案
- 從如何使用到如何實現一個Promise
- 超詳細講解頁面加載過程
原文首發地址點這里，歡迎大家關注公眾號 「前端南玖」
我是南玖，我們下期見！！！