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

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

能夠評估及回報網頁的實際成效,對於長期診斷及改善成效至關重要。如果沒有欄位資料,就無法確認你對網站所做的變更是否確實能達到預期的結果。

許多熱門的 實際使用者監控 (RUM) 分析服務供應商,已在其工具中支援 Core Web Vitals 指標 (以及許多其他 Web Vitals)。如果您目前使用其中一種 RUM 分析工具,就能評估網站上的網頁是否符合建議的 Core Web Vitals 門檻,並防止日後出現回歸現象。

雖然我們建議使用支援 Core Web Vitals 指標的分析工具,但如果您目前使用的分析工具不支援這類指標,則不一定需要更換。幾乎所有數據分析工具都提供方法,可用來定義及評估自訂指標事件,也就是說,您很可能可以使用目前的數據分析供應商來評估核心網站體驗指標,並將這些指標加入現有的數據分析報表和資訊主頁。

本指南將說明使用第三方或自家分析工具評估 Core Web Vitals 指標 (或任何自訂指標) 的最佳做法。這份指南也適用於想在服務中加入 Core Web Vitals 支援功能的數據分析供應商。

使用自訂指標或事件

如上所述,大多數分析工具都允許您評估自訂資料。如果您的數據分析工具支援這項功能,您應該可以使用這個機制評估每項 Core Web Vitals 指標。

在數據分析工具中評估自訂指標或事件通常分為三個步驟:

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

如要瞭解步驟 1 和 3,請參閱分析工具的說明文件。在步驟 2 中,您可以使用 web-vitals JavaScript 程式庫來計算每個 Core Web Vitals 指標的值。

以下程式碼範例說明如何在程式碼中輕鬆追蹤這些指標,並將其傳送至數據分析服務。

import {onCLS, onINP, 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);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

避免使用平均值

您可能會想計算平均值,以便將一系列成效指標值加總起來。乍看之下,平均值似乎很方便,因為它是大量資料的簡潔摘要,但請不要依賴平均值來解讀網頁成效。

平均值有問題,因為它無法代表任何單一使用者的會話。分布範圍內的離群值可能會誤導平均值。

舉例來說,少數使用者可能會使用速度極慢的網路或裝置,導致值偏高,但由於使用者工作階段數量不足,無法影響平均值,因此無法判斷是否有問題。

請盡可能使用百分位數,而非平均值。特定效能指標之間分佈的百分位數,能更好地描述網站的完整使用者體驗。這可讓您專注於實際體驗的子集,比單一值更能提供深入分析。

確認您可以檢舉發布內容

計算出各項 Core Web Vitals 指標的值後,請使用自訂指標或事件將這些值傳送至 Analytics 服務,然後建立報表或資訊主頁,顯示已收集到的值。

為確保符合建議 Core Web Vitals 的門檻,製作報表時需要在第 75 個百分位數顯示每個指標的值。

如果數據分析工具並未以內建功能提供量化報表,您仍可透過產生一份報表,列出所有指標值依遞增順序排序,您還是可以手動取得這項資料。產生此報表後,報表中有 75% 的完整、排序後清單,結果在該指標的第 75 個百分位數。無論您以何種方式 (依裝置類型、連線類型、國家/地區等) 區隔資料,結果都是這樣。

如果分析工具預設不會提供指標層級的報表細目,只要支援自訂維度,應該就能取得相同的結果。為您追蹤的每個指標執行個體設定專屬的自訂維度值後,如果您在報表設定中加入自訂維度,應該就能產生按個別指標例項細分的報表。由於每個例項都有專屬的維度值,因此系統不會進行分組。

網站重要指標報表就是使用 Google Analytics 的這項技術的範例。這份報告的程式碼為開放原始碼,開發人員可以參考這份報告,瞭解本節所述的技術。

Web Vitals 報表的螢幕截圖

在適當時間傳送資料

有些效能指標可在網頁載入完成後計算,其他指標 (例如 CLS) 則會考量網頁的整個生命週期,並在網頁開始卸載後才算出最終結果。

但這可能會造成問題,因為 beforeunloadunload 事件都不可靠 (尤其是行動裝置),而且不建議使用,因為這兩個事件會讓網頁不符合使用往返快取的資格。

對於追蹤網頁整個生命週期的指標,建議您在 visibilitychange 事件中傳送指標的目前值,並在網頁的顯示狀態變更為 hidden 時傳送。這是因為一旦頁面的顯示狀態變更為 hidden,就無法保證該頁面上的任何指令碼能夠再次執行。這點在行動作業系統上尤其重要,因為瀏覽器應用程式本身可以關閉,而不會觸發任何頁面回呼。

請注意,行動作業系統在切換分頁、切換應用程式或本身關閉時,通常會觸發 visibilitychange 事件。關閉分頁或前往新頁面時,也會觸發 visibilitychange 事件。這使得 visibilitychange 事件比 unloadbeforeunload 事件可靠得多。

長期監控成效

更新數據分析導入作業,以便追蹤及回報網站體驗核心指標,接下來請追蹤網站變更對長期效能造成的影響。

管理變更版本

追蹤變更的簡單 (但最終不可靠) 方法,就是將變更部署至實際環境,然後假設部署日期後收到的所有指標都對應至新網站,而部署日期前收到的所有指標則對應至舊網站。不過,許多因素 (包括在 HTTP、服務工作者或 CDN 層級快取) 都可能導致這項功能無法運作。

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

執行實驗

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

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

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

確保評估不會影響效能

在評估真實使用者的成效時,您執行的任何成效評估程式碼絕對不能對網頁成效造成負面影響。如果是這樣,您就無法得知成效對業務的影響,因此無法做出任何結論,因為您永遠無法確定是否是分析程式碼本身造成最大的負面影響。

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

延後數據分析

Analytics 程式碼應一律以非同步、非封鎖的方式載入,且通常應在最後載入。若是以阻礙性的方式載入分析程式碼,可能會對 LCP 造成負面影響。

用於評估 Core Web Vitals 指標的所有 API 均專門設計用於支援非同步和延遲的指令碼載入作業 (透過 buffered 標記),因此您不必急著提早載入指令碼。

如果您要評估的評估指標無法在網頁載入時間表的後續階段計算,請將需要提早執行的程式碼內嵌至文件的 <head> 中 (因此不會造成轉譯阻斷請求),並延後執行其餘程式碼。請勿因為單一指標需要,就提早載入所有 Analytics。

請勿建立長時間的工作

Analytics 程式碼通常是因應使用者輸入而執行,但如果您的分析程式碼執行大量 DOM 測量,或是使用其他處理器密集的 API,數據分析程式碼本身可能會導致輸入回應速度過慢。此外,如果包含分析程式碼的 JavaScript 檔案很大,執行該檔案可能會阻斷主執行緒,並對網頁的Interaction to Next Paint (INP) 造成負面影響。

使用非封鎖式 API

sendBeacon()requestIdleCallback() 等 API 是專門用來執行非重要工作,且不會封鎖使用者重要工作。

這些 API 是 RUM 分析程式庫中非常實用的工具。

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

請勿追蹤不必要的資料

瀏覽器會提供大量效能資料,但即使資料可供使用,也不一定代表您應該記錄並傳送至數據分析伺服器。

舉例來說,Resource Timing API 會針對網頁載入的每個資源提供詳細的時間資料。不過,並非所有資料都會對改善資源載入效能有所幫助。

簡而言之,不要只因為資料存在就追蹤資料,請務必在使用追蹤資料的資源前,先確保資料會被使用。