作者 | 李玲
同一個網站，有的用戶說好用，有的用戶投訴慢，Web性能差嗎？
從用戶角度出發，收集用戶的使用反饋，很多吐槽都提到了慢，經調研用戶最關注的是速度，所以Web性能主要指網站加載、響應速度。它包括客觀的指標和用戶在訪問應用時所感受到的性能情況。主觀的用戶性能感知受到用戶設備、網速快慢和用戶的主觀感受影響，導致性能是相對的。
而談論性能，重要的是精確，并且根據能夠進行定量測量的客觀標準來論及性能。通過什么信息來分析系統性能，如何判定好壞？google提供了思考性能問題的方法論，以用戶為中心的性能模型 - RAIL。
RAIL性能模型
用戶感知到的“性能”是什么?
- 0 - 16ms 動畫流暢
- 0 - 100ms 即時響應
- 1s + 慢，用戶失去耐心
- 10s 以上 非常慢，用戶可能放棄使用
將用戶體驗根據關鍵動作分為4個獨立的模塊：response （響應）、animation（動畫）、idle（瀏覽器空置狀態）和load（加載），結合用戶對時間的感知，明確了對用戶體驗影響最大的性能目標。
如果在每個模塊上，都可以達到性能優化的目標值，那么最終用戶感受到的將會是極致的體驗。
目標與準則
(1) Response 100ms內完成交互
- 50ms內處理完事件
- 對耗時長的操作提供即時反饋，比如說“加載中”的標識。如果用戶點擊后沒有得到任何反饋，用戶會質疑系統是否有問題
(2) RAnimation 流暢的視覺效果
- 動畫并不止酷炫的效果，只要是視圖變化都算動畫，包括滾動，拖拽
- 16ms內生成一幀，達到60fps
(3) RIdle 即時響應用戶
- 盡可能增加空閑時間
- 利用空閑時間
- 始終以用戶操作為最高優先級
(4) RLoad 5s內可操作
- 1s內渲染出主要內容
- 如果無法快速展示頁面全部內容，可以逐步渲染，使其看起來渲染快
與用戶體驗相關的關鍵性能指標
- 在 100 毫秒內響應用戶輸入。
- 播放動畫或執行滾動時，在 10 毫秒內生成一幀。
- 最大限度延長主線程空閑時間。
- 在 5000 毫秒內加載交互式內容。
RAIL性能模型提供了分析系統性能的思路，與用戶體驗相關的關鍵性能指標和實現目標的準則建議。了解用戶對不同關鍵動作所期望的性能，使用Chrome DevTools對加載或運行時的活動進行深入分析，識別性能問題。
Google又提出了更明細的以用戶為中心的性能指標，幫助我們更好的了解真實用戶對Web的整體體驗。
以用戶為中心的性能指標
如何定義性能指標？
從用戶角度出發，考慮以下關鍵問題，從用戶體驗和關心的關鍵節點定義性能指標
- 是否正在發生？導航是否成功啟動？服務器有響應嗎？
- 是否有用？是否渲染了足夠的內容讓用戶可以深入其中？
- 是否可用？頁面是否繁忙，用戶是否可以與頁面進行交互？
- 是否令人愉快？交互是否流暢自然，沒有延遲和卡頓？
性能指標
• First contentful paint 首次內容繪制 (FCP)：頁面開始加載到頁面顯示任何內容的時間。
代表服務器有響應，增大用戶繼續等待的信心
• Largest contentful paint 最大內容繪制 (LCP)：頁面開始加載到最大文本塊或圖像元素在屏幕上完成渲染的時間。
代表有用，有助于讓用戶確信頁面有效
• First input delay 首次輸入延遲 (FID)：用戶第一次與網站交互（比如單擊鏈接、點按按鈕等）直到瀏覽器實際能夠對交互做出響應所經過的時間。
確保頁面的有效性、可交互性
• Time to Interactive 可交互時間 (TTI)：頁面開始加載到能夠快速、可靠地響應用戶輸入所需的時間。
確保頁面的有效性、可交互性
• Total blocking time 總阻塞時間 (TBT)：FCP 與 TTI 之間主線程被阻塞的總時間，期間無法可靠穩定地響應用戶。
確保頁面的可用性，體現了不可交互程度的嚴重性。
• Cumulative layout shift 累積布局偏移 (CLS)：頁面在開始加載和其生命周期狀態變為隱藏期間發生的所有意外布局偏移的累積分數。
確保頁面令人愉快
圖片來源：https://www.lambdatest.com/blog/core-web-vitals-expert-tips-to-improve-website-performance/
從程序員角度解讀
下圖展示了加載一個頁面，瀏覽器主線程和網絡的使用情況，以及各個指標的耗時。
- 用戶訪問頁面，導航開始，瀏覽器與服務器建立連接，獲取html資源，再發出數個網絡請求來獲取所需的js，css資源。
- 這些資源下載完畢后，會在主線程上解析處理執行。這就導致主線程會階段性地處于忙碌狀態（圖中米黃色任務塊）。
- DOM樹構建完成后，開始繪制，頁面渲染出部分內容。首次內容繪制節點即為FCP。
- 如果用戶在FCP后嘗試與頁面進行交互（例如單擊一個按鈕），由于主線程正處于忙碌狀態，響應會有一段延遲，延遲的這段時間即為首次輸入延遲FID。用戶會將較長的延遲認為頁面響應緩慢或者頁面已損壞，因此很可能直接離開。
- 5秒安靜窗口：沒有長任務切不超過兩個正在處理的網絡GET請求，此時瀏覽器主線程空閑并能可靠地響應用戶。
- 可交互時間TTI是安靜窗口前的最后一個長任務的結束時間，是頁面從開始加載到主要子資源完成渲染，并能夠快速、可靠地響應用戶輸入所需的時間。TTI越小越好，說明用戶等待的時間短。
- 用戶收到的阻塞程度則由TTB來體現，每當出現長任務（在主線程上運行超過 50 毫秒的任務）時，主線程都被視作"阻塞狀態"，瀏覽器無法中斷正在進行的任務，長任務超過 50 毫秒的部分為阻塞時間，總阻塞時間是在 FCP 和 TTI 之間發生的每個長任務的阻塞時間總和，體現了不可交互程度的嚴重性。
圖片來源：https://web.dev/fid/
指標閾值
Google將用戶體驗的質量分為三個等級：好、需要改進或差，并設置了以下閾值：
圖片來源：https://developers.google.com/speed/docs/insights/v5/about
這些閾值可以作為行業性能基線，比較我們系統性能指標得分和這些閾值可以了解我們系統對應性能指標的好壞。
自定義性能指標
以用戶為中心的性能指標提供了很好的性能基線，但很多情況我們需要測量更多的指標來刻畫網站的完整體驗。例如：
加載資源的緩存命中率 ：緩存機制設置的是否合理
- 長任務 ：運行開銷大的代碼是否阻塞主線程，比如頻繁計算/過濾50M的數據
- 元素渲染時間：長列表需要多久能繪制到頁面上
- 服務器響應時間：CDN是否正確設置
- API的耗時：在用戶使用應用的生命周期中，增刪改查操作占據很大的比例。用戶也許能忍受用5分鐘打開一個頁面，但無法接受每次提交都要等很久。API也是我們分析性能的重點。
根據系統和需要評估的性能，自定義性能指標，更全面地衡量系統性能。
小結
遇見用戶抱怨性能時，不要先入為主地判定性能差，逐個排查系統可能有的性能問題，優化非最佳實踐。而應該理性地以用戶為中心，收集真實用戶數據，衡量系統性能好壞。
從RAIL性能模型中我們了解用戶眼中的性能意味著什么。用戶對性能延遲的感知，Web應用生命周期中的關鍵動作響應、動畫，空閑，加載的期望閾值，與用戶體驗相關的關鍵性能指標。
以用戶為中心的性能指標更深入地展示了用戶在訪問頁面各個階段的體驗和預期。
還可以自定義性能指標，定制化衡量我們系統的性能。
性能的好壞并不能由某一個性能指標所決定，它是綜合復雜的，需要結合所有性能指標并基于權重來計算最終性能得分。
了解Web性能指標，有助于我們理解用戶眼中的性能，讀懂性能數據，才能發現性能瓶頸。
