　　 一、前言

　　ICBU 作為海外數字商業板塊的常青樹，紮根於全球化的土壤裡，如何做好全球使用者體驗、提升頁面效能已經成為了一個老生常談的話題。

　　面對日益複雜的網路環境，如何做好全球化的前端效能度量，同時更進一步，基於度量做到讓前端開發者更容易發現效能問題、問題都能有解法、解決後能看到效果，本文將根據多年前端效能最佳化的經驗，從如下三個角度進行分享。

　　 二、效能指標採集

　　1. CWV 是什麼？

　　核心 Web 指標是適用於所有網頁的 Web 指標子集，每位網站所有者都應該測量這些指標，並且這些指標還將顯示在所有 Google 工具中。每項核心 Web 指標代表使用者體驗的一個不同方面，能夠進行實際測量，並且反映出以使用者為中心的關鍵結果的真實體驗。

　　CWV，全稱（Core Web Vitals，核心 Web 指標），包含 LCP、CLS、FID 三個指標，分別對應載入效能、互動性和視覺穩定性。　　

　　2. 為什麼使用 FCP + CWV 作為核心指標？

　　選擇使用 FCP + CWV 作為核心指標有以下幾點考慮：

　　我們需要一個統一的、標準的、符合行業規範的【指標】來對全球化場景下的前端效能進行度量；

　　我們需要一個合理的區間來對當下的效能狀態進行更加直觀的展示（優秀、良好、較差）；

　　【指標】本身需要能夠客觀的反應頁面的狀態，儘量減少主觀性，且能指導頁面最佳化方向；

　　3. 為什麼【自定義首屏】不再被作為核心指標？

　　出於歷史原因，ICBU 很長一段時間都使用【自定義首屏】（exposed_time）來作為衡量頁面效能的關鍵指標，但隨著時間推移，我們發現了【自定義首屏】的一些弊端，包括但不限於：

　　容易作弊：【自定義首屏】需要在程式碼中手動上報，上報的時機完全取決於業務開發同學，資料可信度不高

　　缺乏共識：每個團隊對於首屏的定義都不相同，無法用統一的閾值來衡量所有場景的效能，各團隊之間無法拉通、對齊，且與業內公認指標無法進行關聯，比如 SEO 場景，自定義首屏最佳化後無法反饋 SEO 是否最佳化。

　　最佳化困難：【自定義首屏】只能衡量“首屏時間”，當該指標較差需要最佳化時，開發者往往無從下手，因為導致首屏時間變長的因素過多，需要花費大量精力進行問題排查、效能最佳化。

　　指標過於單一：在聊使用者體驗的時候，關注的不應該僅僅是頁面載入的時間，而是頁面載入到使用者與頁面互動的整個生命週期，除了載入效能以外，還應該關注使用者互動延遲、頁面佈局偏移、核心元素載入時機等多維度的指標。

　　4. 為什麼要在 CWV 的基礎上增加 FCP 指標？　　

　　通常來講，【LCP】已經反應大部分場景頁面載入效能的情況，但是對於某些首跳場景、頁面生命週期較短的場景而言，可能無法等到【頁面最大元素】載入完畢就已經跳出了，針對這類場景我們在 CWV 的基礎上再加上了 FCP，來作為衡量頁面載入效能的輔助指標。

　　並且，我們認為，對於使用者而言，【頁面上首次渲染內容】的時機也是非常關鍵的，他可以很好的反應頁面主文件在經過網路請求之後，真正渲染到頁面上的時間差，利於我們在做效能最佳化的時候更精細的進行問題排查。

　　5. 當前的效能指標和業界指標有什麼區別？

　　在選擇閾值的時候主要考慮了兩點因素：

　　形成共識：即我們認為體驗好的頁面，在業內應該是公認的體驗較好，各個團隊間也都應該覺得好；

　　達成難度：如果想要得到一個極致體驗的頁面，各項指標應該是定的越高越好，但實際卻不是這樣。過高的閾值會讓效能最佳化的 ROI 降低，讓開發者覺得高山仰止；

　　基於這兩點，目前的前端核心效能指標完全 follow 了 Google 提供的指標閾值，並在其基礎上針對國際化場景現狀進行了微調，例如 FCP 指標，參考了【自定義首屏】的衡量標準，對各階段的閾值進行了部分調整，使其在不影響使用者體驗的情況下更易於達成。

　　在展示資料的 75 百分位值的同時，效能平臺也增加了 90 分位值、中位數、平均值等多個維度資料的展示，我們鼓勵開發者從不同視角對效能進行評估，更多的探索極致效能、極致體驗。

　　6. CWV 指標閾值設定的背景是什麼？

　　如果把 FCP 的優秀區間設為 0-0.1s，從指標上來看的確很優秀，但是又有幾個網站能做到這麼極致？所以這樣來定閾值不具備任何參考價值。在 Google 評估如何設定閾值時，會根據 Chrome 使用者體驗報告 (CrUX) 中的資料來驗證這些閾值是否可以實現，為了確保該閾值可實現，要求至少有 10% 的使用者滿足該閾值的條件，並且會根據實際資料的變化不斷進行調整。

　　基於各類文獻可以得出，各個指標閾值的設定主要基於以下兩點：

　　體驗質量

　　可實現性

　　6.1 LCP 的取值依據

　　體驗質量：

　　基於“一秒鐘原則”，我們通常認為，使用者對一項任務失去注意力的等待時間為 1s，Google 研究發現，1s 這個值是用來描述一個區間的近似值，這個區間從幾百毫秒到幾秒不等。

　　1 秒閾值的兩個常見引用來源是卡德等人和米勒。卡德透過引用紐厄爾的認知統一理論，定義了 1 秒的"立即響應"閾值。紐厄爾將立即響應解釋為"必須在大約一秒鐘內對某些刺激作出的響應（即大約從 0.3 秒到 3 秒）。"紐厄爾在此之前就"認知的實時約束"展開過討論，其中指出"與環境互動引發的認知計算是以秒計的"，範圍從大約 0.5 秒到 2-3 秒。1 秒閾值的另一個常見引用來源是米勒，他指出"如果響應延遲超過兩秒（可能超出時長為一秒左右），那麼人類可以透過且將會透過機器通訊執行的任務將發生嚴重的特徵改變。"

　　基於以上研究，LCP （最大內容繪製）的“良好”閾值應該在 0.3s-3s 之間，由於 FCP （首次內容繪製）的“良好”閾值為 1.8s（2021 年更新的資料），所以最終 LCP 的“良好”候選閾值應該在 1.8s-3s 之間。

　　可實現性：

　　確定好閾值之後我們再來看能夠滿足候選“良好”閾值所佔的百分比，從 CrUX 的資料我們可以看到：　　

　　只有不到 10% 的域滿足 1s 的閾值，但 1.5 秒到 3 秒之間的其他所有閾值也都滿足我們的要求，即至少有 10% 的域滿足"良好"閾值，因此這些閾值仍然是有效的候選值。

　　此外，為了確保所選取的閾值對於最佳化良好的網站始終都可實現，我們分析了全網表現最出色的網站的 LCP 效能，從而確定哪些閾值對於這些網站是始終都可實現的。具體來說，我們的目標是確定一個對於表現最出色的網站來說，始終可以在第 75 個百分位數實現的閾值。我們發現，1.5 秒和 2 秒的閾值並不是始終都可以實現的，而 2.5 秒的閾值是始終可以實現的。

　　6.2 CLS 的取值邏輯

　　體驗質量：

　　累積佈局偏移 (CLS) 是一項新指標，用於測量頁面可見內容的偏移量。鑑於 CLS 是一項全新指標，我們不知道能夠直接為該指標的閾值提供參考的研究。因此，為了確定一個符合使用者期望的閾值，我們對具有不同佈局偏移量的真實世界頁面進行了評估，進而確定在對享受頁面內容造成嚴重干擾之前，使用者可接受的最大偏移量。在我們的內部測試中，我們發現 0.15 及以上的偏移水平始終被認為具有干擾性，而 0.1 及以下的偏移水平雖然可以被注意到，但不具有過度干擾性。因此，雖然零布局偏移是理想情況，但我們得出的結論是，0.1 及以下的值是 CLS 的候選"良好" 閾值。

　　可實現性：　　

　　雖然 CrUX 資料表明 0.05 可能是一個合理的 CLS "良好"閾值，但我們認識到，目前在某些用例中還難以避免干擾性的佈局偏移。例如，對於如社交媒體嵌入這樣的第三方嵌入內容，嵌入內容的高度有時在完成載入之前是未知的，這就可能導致佈局偏移大於 0.05。因此，我們的結論是，雖然許多域都滿足 0.05 的閾值，但將 CLS 閾值定為略微寬鬆一點的 0.1 能夠在體驗質量和可實現性之間取得更好的平衡。我們希望網路生態系統在未來能夠確定一個針對由第三方嵌入引起的佈局偏移的解決方案，這將使我們能夠在核心 Web 指標的未來迭代中採用 0.05 或 0 這兩個更為嚴格的 CLS "良好"閾值。

　　6.3 FID 的取值邏輯

　　體驗質量：

　　雅各布·尼爾森 (Jakob Nielsen) 撰寫的響應時間：3 個重要界限常常被引用，文章中將 0.1 秒定義為使用者感覺到系統立即做出反應的界限。

　　在實現時間性的完美虛擬按鈕一文中，卡雷索亞 (Kaaresoja) 等人研究了在不同的延遲下，觸控觸屏上的虛擬按鈕和隨後顯示按鈕被觸控的視覺反饋之間的同時性感知。當按下按鈕和視覺反饋之間的延遲為 85 毫秒或更短時，參與者在 75% 的情況下報告視覺反饋是在按下按鈕的同時出現的。此外，對於 100 毫秒或更短的延遲，參與者報告的按下按鈕的感知質量始終很高，而感知質量在 100 毫秒到 150 毫秒的延遲下有所下降，並且在 300 毫秒的延遲下達到非常低的水平。

　　鑑於上述研究，Google 得出結論，100ms 左右的延遲值範圍是 Web 指標合適的首次輸入延遲閾值。此外，鑑於使用者在 300 毫秒或更長的延遲下報告了低質量級別，則 300 毫秒為合理的"欠佳"閾值。

　　可實現性：

　　據 Google 觀察，全網最出色的網站始終能夠在第 75 個百分位數上（並且通常在第 95 個百分位數上）滿足此閾值，所以 100ms 是合理的 FID “良好” 閾值。　　

　　 三、效能資料分析

　　1. 多通道資料流轉　　

　　在資料流轉通道的設計上，為了相容多端的效能資料採集和舊的採集邏輯，我們採用了多通道 + 對照組的方式。

　　多通道（Web + App）：

　　Web：黃金令箭多點位對效能資料進行採集

　　App：UT 通道，保障資料傳輸效率和完整性

　　對照組（SLS）：

　　同時將資料取樣傳送至 SLS，用於資料對比，資料準確性矯正；

　　2. 多維度聚合分析

　　為了滿足開發者的效能分析訴求，我們需要對採集上報的效能資料進行多維度的聚合處理，區別於以往的取平均值進行分析，我們對取值範圍進行了擴充，包括（75 百分位、中位數、90 百分位），用於分析長尾效能資料、規避離群值對整體效能的影響。

　　同時基於場景、URL、spm_id、國家、端型等多個維度，對效能資料進行聚合，讓開發者能透過不同視角進行效能分析，保障效能分析的準確性。

　　3. 為什麼預設取 75 百分位值？

　　參考一些業內各類文獻，選擇 75 百分位值的原因基於如下兩個標準：

　　選取的百分位值應當確保對頁面或網站的大多數訪問都達到了目標效能水平

　　選取的百分位值應當不受異常值的過度影響

　　這兩點如何解釋呢？

　　首先是第一點，通俗一點講就是應該選擇一個高百分位值，也就是大部分頁面都能實現的值，但是隨著百分位值的升高，結果值受異常資料影響的可能性就越大。

　　其次是第二點，如果我們為了滿足第一個標準，可以選擇一個較高的百分位（例如：95 百分位數）作為閾值，但是隨著百分位數的增加，其結果值越容易受到異常資料的影響。比如我們使用 95 百分位數對頁面進行評估，頁面總共採集了 100 條資料，如果其中有 5 條資料是異常值，那麼第 95 百分位數就會收到異常值的影響。

　　綜上所述，為了兼顧兩個目標，分析得出 75 百分位值更接近合理的平衡點，在採用 75 百分位值時，大多數網站都能達到效能水平或者更高，且 100 條資料中，只有當異常資料達到 25 條時，才會對結果值造成影響，機率相較於 95 百分位值更低，結果值的可信度更高。

　　 四、效能報表展示

　　基於分析的資料需要找到合適的報表進行效能資料的展示，同時為了提供全球化的視野，效能平臺進行了一系列的定製開發。

　　1. 核心效能指標卡片　　