如何做好全球化的前端效能度量?
來源:阿里開發者
一、前言
二、效能指標採集
1. CWV 是什麼?
核心 Web 指標是適用於所有網頁的 Web 指標子集,每位網站所有者都應該測量這些指標,並且這些指標還將顯示在所有 Google 工具中。每項核心 Web 指標代表使用者體驗的一個不同方面,能夠進行實際測量,並且反映出以使用者為中心的關鍵結果的真實體驗。
2. 為什麼使用 FCP + CWV 作為核心指標?
選擇使用 FCP + CWV 作為核心指標有以下幾點考慮:
我們需要一個統一的、標準的、符合行業規範的【指標】來對全球化場景下的前端效能進行度量;
我們需要一個合理的區間來對當下的效能狀態進行更加直觀的展示(優秀、良好、較差);
【指標】本身需要能夠客觀的反應頁面的狀態,儘量減少主觀性,且能指導頁面最佳化方向;
3. 為什麼【自定義首屏】不再被作為核心指標?
出於歷史原因,ICBU 很長一段時間都使用【自定義首屏】(exposed_time)來作為衡量頁面效能的關鍵指標,但隨著時間推移,我們發現了【自定義首屏】的一些弊端,包括但不限於:
容易作弊:【自定義首屏】需要在程式碼中手動上報,上報的時機完全取決於業務開發同學,資料可信度不高
缺乏共識:每個團隊對於首屏的定義都不相同,無法用統一的閾值來衡量所有場景的效能,各團隊之間無法拉通、對齊,且與業內公認指標無法進行關聯,比如 SEO 場景,自定義首屏最佳化後無法反饋 SEO 是否最佳化。
最佳化困難:【自定義首屏】只能衡量“首屏時間”,當該指標較差需要最佳化時,開發者往往無從下手,因為導致首屏時間變長的因素過多,需要花費大量精力進行問題排查、效能最佳化。
指標過於單一:在聊使用者體驗的時候,關注的不應該僅僅是頁面載入的時間,而是頁面載入到使用者與頁面互動的整個生命週期,除了載入效能以外,還應該關注使用者互動延遲、頁面佈局偏移、核心元素載入時機等多維度的指標。
4. 為什麼要在 CWV 的基礎上增加 FCP 指標?
5. 當前的效能指標和業界指標有什麼區別?
在選擇閾值的時候主要考慮了兩點因素:
形成共識:即我們認為體驗好的頁面,在業內應該是公認的體驗較好,各個團隊間也都應該覺得好;
達成難度:如果想要得到一個極致體驗的頁面,各項指標應該是定的越高越好,但實際卻不是這樣。過高的閾值會讓效能最佳化的 ROI 降低,讓開發者覺得高山仰止;
6. CWV 指標閾值設定的背景是什麼?
基於各類文獻可以得出,各個指標閾值的設定主要基於以下兩點:
體驗質量 可實現性
6.1 LCP 的取值依據
體驗質量:
1 秒閾值的兩個常見引用來源是卡德等人和米勒。卡德透過引用紐厄爾的認知統一理論,定義了 1 秒的"立即響應"閾值。紐厄爾將立即響應解釋為"必須在大約一秒鐘內對某些刺激作出的響應(即大約從 0.3 秒到 3 秒)。"紐厄爾在此之前就"認知的實時約束"展開過討論,其中指出"與環境互動引發的認知計算是以秒計的",範圍從大約 0.5 秒到 2-3 秒。1 秒閾值的另一個常見引用來源是米勒,他指出"如果響應延遲超過兩秒(可能超出時長為一秒左右),那麼人類可以透過且將會透過機器通訊執行的任務將發生嚴重的特徵改變。"
可實現性:
只有不到 10% 的域滿足 1s 的閾值,但 1.5 秒到 3 秒之間的其他所有閾值也都滿足我們的要求,即至少有 10% 的域滿足"良好"閾值,因此這些閾值仍然是有效的候選值。 此外,為了確保所選取的閾值對於最佳化良好的網站始終都可實現,我們分析了全網表現最出色的網站的 LCP 效能,從而確定哪些閾值對於這些網站是始終都可實現的。具體來說,我們的目標是確定一個對於表現最出色的網站來說,始終可以在第 75 個百分位數實現的閾值。我們發現,1.5 秒和 2 秒的閾值並不是始終都可以實現的,而 2.5 秒的閾值是始終可以實現的。
體驗質量:
累積佈局偏移 (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 "良好"閾值。
體驗質量:
雅各布·尼爾森 (Jakob Nielsen) 撰寫的響應時間:3 個重要界限常常被引用,文章中將 0.1 秒定義為使用者感覺到系統立即做出反應的界限。 在實現時間性的完美虛擬按鈕一文中,卡雷索亞 (Kaaresoja) 等人研究了在不同的延遲下,觸控觸屏上的虛擬按鈕和隨後顯示按鈕被觸控的視覺反饋之間的同時性感知。當按下按鈕和視覺反饋之間的延遲為 85 毫秒或更短時,參與者在 75% 的情況下報告視覺反饋是在按下按鈕的同時出現的。此外,對於 100 毫秒或更短的延遲,參與者報告的按下按鈕的感知質量始終很高,而感知質量在 100 毫秒到 150 毫秒的延遲下有所下降,並且在 300 毫秒的延遲下達到非常低的水平。
可實現性:
三、效能資料分析
1. 多通道資料流轉
多通道(Web + App):
Web:黃金令箭多點位對效能資料進行採集
App:UT 通道,保障資料傳輸效率和完整性
對照組(SLS):
同時將資料取樣傳送至 SLS,用於資料對比,資料準確性矯正;
2. 多維度聚合分析
3. 為什麼預設取 75 百分位值?
參考一些業內各類文獻,選擇 75 百分位值的原因基於如下兩個標準:
選取的百分位值應當確保對頁面或網站的大多數訪問都達到了目標效能水平
選取的百分位值應當不受異常值的過度影響
四、效能報表展示
1. 核心效能指標卡片
篩選框:可以根據日期、地區、端型進行資料篩選
總取樣 PV,指當前採集到效能資料的條數
核心指標模組:
指標分級:資料異常(紫色)、較差(紅色)、良好(橙色)、優秀(綠色)
指標趨勢:展示當前指標較昨日的變化情況,綠色為下降,紅色為上升。(這裡的核心指標下降都是向好趨勢)
2. 效能最佳化方案
指標狀態:會根據當前情況展現指標分級後的中文描述(資料異常、較差、良好、優秀)
解決方案:會根據現有沉澱的效能解決方案給出建議
3. 頁面主文件 - 網路載入鏈路分析圖
4. 實時資料趨勢圖
基於 SLS 通道,實現全球效能資料的實時觀測
5. 全球流量分佈圖
全球流量分佈:按 pv 排序,可以根據對應的國家進行資料下鑽
6. 使用者效能分佈圖(Google CrUX 資料)
指標分級佔比:該直方圖展示的是 URL 在各級別區間的佔比,拿圖中 FCP 指標舉例,可以理解為該頁面 FCP 指標優秀佔比為 52.70%,良好佔比為 30.12%,剩下的則為較差的級別。
75 百分位值:圖中箭頭所指的 p75 資料為 Google 分析的使用者資料排行第 75 百分位的值,指向的區域顏色代表了網站當前的效能情況(綠色:優秀、橙色:良好、紅色:較差)。
五、小結
參考連結:
定義核心 Web 指標閾值:https://web.dev/defining-core-web-vitals-thresholds/ 認知統一理論: 響應時間:3 個重要界限: 因果關係感知: 實現時間性的完美虛擬按鈕: Web Vitals Changelog: CWV 等體驗指標納入 Google 搜尋排名:https://developers.google.com/search/blog/2020/11/timing-for-page-experience CWV FAQ:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024924/viewspace-2929906/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 機器學習之常見的效能度量機器學習
- 做好陪玩系統原始碼的前端效能優化,提升系統效能原始碼前端優化
- 度量Web效能的關鍵指標Web指標
- 聊聊效能度量的作弊經濟學
- 機器學習中的效能度量指標彙總機器學習指標
- SQL效能的度量 - CBO最佳化方式SQL
- 如何提升Web前端效能?Web前端
- 聊聊需求的價值如何度量
- 如何衡量前端基建的效能價值?前端
- 如何提升前端基建的效能價值?前端
- 實戰篇:如何做好SOAP介面效能測試?
- 如何提高前端效能——字型篇前端
- SQL效能的度量 - 語句級別的SQL跟蹤autotraceSQL
- 如何比設計更懂設計-做好前端錯誤提示前端
- Oracle效能優化使用度量和預警Oracle優化
- 分類任務中效能度量及程式碼
- 怎麼做好Java效能優化Java優化
- 乾貨收藏 | 如何優化前端效能?優化前端
- 從案例分析如何優化前端效能優化前端
- 前端效能優化 —— 前端效能分析前端優化
- SQL效能的度量 - 會話級別的SQL跟蹤sql_traceSQL會話
- 天美J3客戶端負責人:全球化研發浪潮中,我們如何做好準備?客戶端
- 前端效能如何體系化?HeapDump效能社群和前端早早聊深度深度合作探索答案!前端
- 如何精確度量 iOS App 的啟動時間iOSAPP
- 雙十一特輯 · 買買買的背後,電商如何做好前端優化?(一)前端優化
- SQL效能的度量 - 利用Hints和dbms_sqltune進行SQL監控SQL
- SQL效能的度量 - 利用10046事件擴充套件SQL跟蹤SQL事件套件
- 如何做好Code ReviewView
- devops|中小公司不要做研發效能度量dev
- SQL效能的度量 - 透過v$sql_plan查詢執行計劃SQL
- 前端效能優化的點前端優化
- 如何做好遊戲中的成就係統?遊戲
- 如何做好資料分析
- “前端”工匠系列(二):合格的工匠,怎麼做好價值落地前端
- SQL效能的度量 - 透過explain和dbms_xplan包分析執行計劃SQLAI
- 全球化時代如何捍衛網路主權
- 數字化時代,如何做好使用者體驗與應用效能管理
- Scrum 的收益沒法度量?Scrum