數據包括性能指標、監控數據以及通過埋點得到的業務數據，而數據分析是體驗優化的最后一環。   通過數據來量化當前的工作，從而證明工作是否高效，優化是否有效等問題。   量化的工作包括代碼質量和業務數據。 ## 一、代碼質量   代碼質量的數據來源于思維導圖中的性能指標和監控體系，包括 SLA、慢響應、前端錯誤、白屏和首屏時間等，以折線圖的形式描述趨勢變化。   因為我們組維護著大量的 Node 服務，所以指標中就會包含多個服務端數據。其中慢響應作為我們組的北極星指標。   所謂北極星指標，也叫第一關鍵指標，是指在產品的當前階段與業務/戰略相關的核心指標，一旦確立就像北極星一樣指引團隊向同一個方向前進。 **1）SLA**   SLA 是指服務質量保證，參考的指標是異常狀態碼接口占比，即報 500、502、503 和 504 的接口。   其中 500 是代碼錯誤，我們可以通過日志做排查。我們公司要求 SLA 的值要至少達到 5 個 9，即 99.999XX%。   如果要實現 6 個 9，按照我們公司每日的體量，每天只能允許 4 個以內的接口異常，維護成本比較大。?   在 500 的錯誤碼中，監控接口占據了 94% 左右，主要是因為上傳的數據量太大導致報錯，服務端限制 1M，最終在上傳時就做大小限制。   還有一個占據了 6.2% 的錯誤接口主要是邏輯不夠嚴密，邊界條件沒有處理好，修復后就降到了 0。   502 是轉發的后端服務不存在，503 是沒有轉發或服務掛起，如果大量報，可以去找下運維。   504 是由后端服務出問題導致的超時引起的，例如數據庫因為一條耗時的查詢語句而被掛起。 **2）慢響應**   慢響應是那些響應時間超過 2 秒的接口，在內部又將慢響應分為對外業務慢響應和對內后臺慢響應，主要精力會放到對外業務上。   公司要求對外的慢響應占比要控制在萬分之 2 以內，對內就比較松，只要不是很慢，可以操作就行。   造成慢響應的原因有一種是內部邏輯慢，另一種是受調用的接口影響而變慢。   第一種就可以我們自己解決，第二種就需要找協作組配合解決了。   有一個占了業務慢響應 67.4% 數量的監控列表接口，屬于前者，在內部會查詢一張 430W 的大表 6 次。   優化手段也很直接，就是減少查詢次數，降到 1 次，慢響應次數一下子減少了 95%。   還有個舉報接口，也屬于前者，這張表也比較大，增加查詢條件，觸發索引，就立竿見影的把速度提上來了。   該慢響應次數一下子減少了 90%。這兩個接口優化后，業務慢響應總占比從萬分之 0.23 降低到萬分之 0.1。   有一個內容審核的服務，由于架構缺陷導致優化成本很高，后面直接遷移后，后臺慢響應占比從最高的萬分之 98.13 降低到萬分之 9.79。 **3）前端錯誤**   前端錯誤就是通過監控系統搜集到的錯誤日志，分為腳本錯誤和通信異常。   腳本錯誤就是 JavaScript 的異常，例如用 undefined 當對象讀取屬性。   一個項目中的腳本錯誤在修復后，從高峰的 4073 降低至246，減少了 93.96%，進一步的保障項目質量。   雖然也能搜集圖像請求的錯誤，但是卻不能獲取到錯誤原因，可能是用了代理或靜態服務器偶爾的波動。   曾經在內容審核的頁面，有段時間每日上報的圖像錯誤最高達到 28827，之后動態的將圖像質量降低 70%，錯誤上報量從降低至 1641。   通信異常其實也是 500、502 和 504 接口，之前的接口異常數量會包括靜態資源以及內部的服務調用。   而此處的通信異常只包含從客戶端發起的那部分接口，可以簡單理解為其子集，不過有時候發現 502 和 504 的統計兩邊會有略微差異。 **4）白屏和首屏時間**   白屏就是等待白屏的時間（FP），首屏更確切的說是首次有意義的內容加載時間（FMP）。   之前做過一套性能監控系統，白屏比較好計算，而首屏比較復雜，我們這邊采用最簡單的埋點的方式。   也就是手動的在某個階段記錄首屏時間，比較麻煩的是需要將線上頁面逐個添加，不過也沒多少個，所以還能接受這個笨辦法。   以首屏為例，1 秒內占 72%左右，2 秒內占 19% 左右，若以 1.2 秒為邊界的話，那優化的空間還是蠻大的。   初步排查后，發現主要慢在 DOM 解析，這讓我蠻詫異的，經過 Chrome DevTools 的性能分析后，定位到了腳本尺寸上。   加載的腳本有點多，并且有一個 chunk-vendors.js 腳本還比較大，下載時間有點長。   因此在加載和運行時就會延長 DOM 的解析，影響白屏時間。 ## 二、業務數據   業務數據大多來源于分布在頁面各處的埋點，經過數據分析后能得出各類報表，可以直觀的查看業務是在增長還是下降亦或是持平。   在體驗優化后，查看下相關數據的前后變化，就能知道此次優化是否成功了。   我們組的工作效率也是業務數據的一部分，但是這塊比較難量化，不可能通過代碼行數來判別，因此就想到了需求提測率和雙月用戶滿意度評分。 **1）需求提測率**   公司每雙月會開一次需求討論會，羅列本雙月的需求。   我會以這份列表為基礎，自己再開一份在線列表，記錄所有需求的狀態，并且會將不在此列表中的零碎需求也記錄。   這份列表有 5 列，包括需求名稱、線上BUG數、功能點數量、狀態和備注。   其中狀態又包括設計、提測、上線、延期等，可以一眼就能反映出需求所處的階段。   線上 BUG 數就是字面意思，而功能點數量是 QA 提供的，他們在寫測試用例時就會有這個數據。   不過沒多久，線上 BUG 數和功能點數量沒有維護起來，因為很多管理后臺需求經常都不寫用例，而活動比較常規，結構差不多也就不會細寫。   線上 BUG 數因為每次都比較少的，偶爾會有幾個，所以也就不怎么寫了。   我的需求提測率是按提測狀態來統計，而不是上線狀態。   因為有時候是需要多端聯調的，經常會碰到協作方因為種種原因無法配合聯調或延期。   提測是指 QA 可以驗收需求，所以要說明此處的聯調問題并不是指我們寫好界面，然后等服務端給接口。   而是比如我們完成管理后臺的前后端功能，提供數據源，服務端沒有時間處理這批數據，類似于這種場景。 **2）雙月用戶滿意度評分**   這是一張問卷調查，滿分是 5 分，收集大家對我們組工作的反饋，對當前存在的問題可以做出針對性的優化。   需要填寫所處部門，需求類型（后臺或活動），是否達到預期，維度包括成果、溝通、響應等。   最后還有兩個可選項，就是填寫意見或建議，以及最想表揚的同學及其理由。   若是正面反饋，那自然很好；若是負面反饋，那就要總結。   在實際執行后，發現大家很少會提意見，每次的分值也差不多。   但是每次點名表揚的都比較多，大家對我們組的工作都比較滿意。 **3）北極星指標**   我們公司每個組都會有北極星指標（例如用戶新增數、XX營收、主動聊天率等），了解各個組的指標變化其實就能了解公司業務的變化。   公司每個組長都會要求填寫雙月的 OKR，OKR 的內容其實也是圍繞著北極星指標來的，閱讀每周的備注，也能了解些業務變化。   如果有條件的話，那些細分下來支撐北極星指標的各類核心指標也可以去了解下。   以會員為例，包括日付費人數、日下單量、首次充值人數、連續包月續訂人數、會員購買 UV 等。   在更好的理解業務后，并且有數據支撐，相信能更容易、更科學的找到真正需要優化的點，做到技術賦能業務增長。 ***** > 原文出處： [博客園-前端體驗優化](https://www.cnblogs.com/strick/category/2360021.html) [知乎專欄-前端性能精進](https://www.zhihu.com/column/c_1610941255021780992) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。