實際評估網站體驗指標的最佳做法

如何使用目前的數據分析工具評估網站體驗指標。

此外,能否評估網頁實際成效並製作報表,是長期診斷和改善效能的關鍵。如果沒有現場資料,就無從得知您對網站變更是否確實能達成預期結果。

許多熱門的實際使用者監控 (RUM) 分析供應商已開始在自家工具 (以及許多其他網站體驗指標) 中支援「網站體驗核心指標」指標。如果您正在使用這些 RUM 分析工具,可以先評估網站上的網頁是否符合建議的網站體驗核心指標門檻,並防止日後發生迴歸問題。

雖然我們建議使用支援 Core Web Vitals 指標的分析工具,但如果您使用的分析工具不支援這些指標,則不一定需要切換。幾乎所有數據分析工具都提供定義及評估自訂指標事件的方法,這表示您可以使用目前的分析供應商評估 Core Web Vitals 指標,並將其新增至現有的數據分析報表和資訊主頁。

本指南說明使用第三方或內部分析工具評估網站體驗核心指標 (或任何自訂指標) 指標的最佳做法。對於希望為自家服務新增網站體驗核心指標支援的分析服務供應商,也可以參考這份文件。

使用自訂指標或事件

如上所述,大部分的分析工具都能用來評估自訂資料。如果您的分析工具支援這項功能,您應該就能利用這項機制評估每個 Core Web Vitals 指標。

使用分析工具評估自訂指標或事件時,通常分為三個步驟:

  1. 如有需要,請在工具的管理員中定義或註冊自訂指標。(注意:並非所有分析供應商都要求事先定義自訂指標。)
  2. 在前端 JavaScript 程式碼中計算指標值。
  3. 將指標值傳送至您的分析後端,確保名稱或 ID 與步驟 1 中定義的名稱或 ID 相符 (如有需要,也會再次說明)

如要瞭解步驟 1 和 3,請參閱數據分析工具的說明文件以參閱操作說明。在步驟 2 中,您可以使用 web-vitals JavaScript 程式庫計算每個網站體驗核心指標指標的值。

下列程式碼範例顯示,透過程式碼中追蹤這些指標並傳送至數據分析服務有多容易。

import {onCLS, onFID, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);

避免平均

您可能會想透過計算平均值來加總效能指標的某個範圍值。平均值對大量資料一目瞭然,因此看起來比較方便,但也建議您避免仰賴這些數據解讀網頁效能。

平均值是有問題的,因為它並不代表任何單一使用者的工作階段。任一分佈範圍的離群值可能會以誤導的方式造成平均值的偏差。

舉例來說,少數使用者可能在使用極慢速度極慢的網路或裝置,而達到最大數值範圍,但卻未將足夠的使用者工作階段計入平均值,以表示有問題。

請盡可能採用百分位數,而非平均值。特定成效指標在分佈情形中的百分位數,可以更準確地描述網站在各種使用者體驗中的體驗。這可讓您專注於「實際」體驗的子集,相較於單一值可能產生的單一值,您將能取得更深入的深入分析資訊。

確認您可以回報分佈情形

計算每個 Core Web Vitals 指標的值,並使用自訂指標或事件傳送至數據分析服務後,下一步就是建構顯示已收集值的報表或資訊主頁。

為確保您能達到建議的網站體驗核心指標門檻,您將需要報表顯示每個指標的第 75 個百分位數的值。

如果分析工具的內建功能並非以分位數報表提供,您仍可以產生一份報表,列出每個指標值依遞增順序排序,藉此手動取得這項資料。系統產生這份報表後,整份報表中所有值的經過排序清單會佔 75%,結果會是該指標的第 75 個百分位數,無論您如何依據裝置類型、連線類型、國家/地區等區隔資料區隔資料,都會計入報表。

如果分析工具預設不提供指標層級的報表精細程度,但您的分析工具支援自訂維度,則可能可以達到相同的結果。只要在報表設定中加入自訂維度,就能為您追蹤的每個指標例項設定不重複的自訂維度值,產生依個別指標例項細分的報表。由於每個執行個體都有不重複的維度值,因此系統不會分組。

網站體驗指標報表是這項技術使用 Google Analytics (分析) 的範例。報表的程式碼為開放原始碼,因此開發人員可參考這份報表,做為本節所述技巧的範例。

網站體驗指標報告的螢幕截圖

在適當時機傳送資料

某些成效指標可以在網頁完成載入後開始計算,而其他指標 (例如 CLS) 則會考量網頁的整個生命週期,而且在頁面開始卸載後才會開始最終成效。

但這可能會發生問題,因為 beforeunloadunload 事件並不可靠 (特別是在行動裝置上),而且不建議使用 (因為它們會導致網頁無法使用往返快取)。

對於追蹤網頁整個生命週期的指標,建議您在 visibilitychange 事件期間,每當頁面顯示狀態變更為 hidden 時,就傳送指標目前的值。這是因為一旦網頁的顯示設定狀態變更為 hidden,就無法保證該網頁上的所有指令碼都可以再次執行。在行動裝置作業系統上更是如此,因為瀏覽器應用程式本身可在不觸發任何網頁回呼的情況下關閉。

請注意,行動作業系統通常會在切換分頁、切換應用程式或關閉瀏覽器應用程式時觸發 visibilitychange 事件。而且會在關閉分頁或導覽至新頁面時觸發 visibilitychange 事件。因此,visibilitychange 事件比 unloadbeforeunload 事件可靠。

持續監控成效

更新分析實作方式,以便追蹤網站體驗核心指標指標並製作報表後,下一步就是追蹤網站變更對效能的影響。

版本變更

一種簡單 (且終極不可靠) 追蹤變更的方法,是將變更部署到實際工作環境,然後假設部署日期後收到的所有指標都會對應到新站,而部署日期前收到的所有指標都會對應到舊網站。但是,任意數量的因素 (包括在 HTTP、Service Worker 或 CDN 層進行快取) 都可能導致這種情形。

更好的做法是為每個已部署的變更建立專屬版本,然後在分析工具中追蹤該版本。大部分的分析工具都支援設定版本。如果不是,您可以建立自訂維度並將維度設為已部署的版本。

執行實驗

您也可以同時追蹤多個版本 (或實驗),進一步進行版本管理。

如果您的分析工具可讓您定義實驗群組,請使用該功能。 或者,您可以使用自訂維度,確保每個指標值都與報表中的特定實驗群組相關聯。

透過在數據分析中進行實驗後,您可以對部分使用者推出實驗變更,並將變更的成效與控制組使用者的成效進行比較。確定變更確實可以提升效能後,即可向所有使用者推出變更。

確認評估不會影響成效

評估實際使用者的效能時,您務必要執行的任何效能評估程式碼,都不會對網頁效能造成負面影響。如果存在,則您在試圖影響效能對業務的影響時,所得出的結論將難以穩定,因為您無法知道分析程式碼本身是否會有最大的負面影響。

在實際執行網站上部署 RUM 分析程式碼時,請務必遵循以下原則:

延後分析結果

Analytics (分析) 程式碼應一律以非同步且非阻塞的方式載入,而且通常應在最後載入。如果在區塊中載入分析程式碼,可能會對 LCP 造成負面影響。

所有用於評估網站體驗核心指標指標的 API 是專為支援非同步和延遲載入指令碼設計 (透過 buffered 標記) 設計,因此您無需急著等待指令碼載入。

如果您要評估的指標稍後無法在網頁載入時間軸中計算,請「只」內嵌需要在文件的 <head> 中提前執行的程式碼 (因此不是禁止轉譯要求),並延後其餘部分。請勿因為單一指標需要,就提早載入所有數據分析資料。

不要建立長時間的工作

Analytics (分析) 程式碼通常會為了回應使用者輸入內容而執行,但如果您的分析程式碼會進行大量 DOM 測量,或是使用其他處理器密集的 API,分析程式碼本身就可能會導致輸入回應不佳。另外,如果包含數據分析程式碼的 JavaScript 檔案很大,執行該檔案可能會封鎖主執行緒,並對首次輸入延遲 (FID)下一個顯示的內容互動 (INP) 造成負面影響。

使用非阻斷 API

sendBeacon()requestIdleCallback() 等 API 經過特別設計,用於執行非重要工作,且不會封鎖使用者重要工作。

這些 API 是適合在 RUM 數據分析程式庫中使用的實用工具。

一般來說,所有分析信標都應使用 sendBeacon() API (如有) 傳送,且所有被動分析評估程式碼都應在閒置期間執行。

不要追蹤不必要的內容

瀏覽器會公開大量效能資料,但這不表示您需要記錄資料並傳送至分析伺服器。

舉例來說,Resource Timing API 會針對您網頁上載入的每個資源提供詳細時間資料。 但是,在改善資源載入效能的情況下,不太可能讓這些資料都不一定有用或有用。

簡而言之,不要只因為記錄資料而追蹤資料,請在使用資源追蹤之前確認資料使用方式。