本頁面由 Cloud Translation API 翻譯而成。

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

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

Philip Walton

能夠評估並記錄廣告活動的實際成效網頁對長期診斷及改善成效而言至關重要。不含欄位資料因此無法確定你對網站所做的變更是否生效確實達到預期成果

許多熱門的真人使用者監控 (RUM) 分析服務供應商已支援 Core Web Vitals 指標工具 (以及其他 Web Vitals 中的許多功能)如果您是正在使用其中一種 RUM 分析工具評估你網站上的網頁是否符合建議的網站體驗核心指標臨界值，避免發生迴歸問題

雖然建議使用支援 Core Web Vitals 的分析工具若您目前使用的分析工具不支援這些指標就算沒有改用幾乎所有數據分析工具定義及測量指標或事件，意味著能使用您目前的分析服務供應商來評估 Core Web Vitals 指標，然後加進您現有的 Analytics 報表和資訊主頁。

本指南將探討使用第三方或內部分析工具評估 Core Web Vitals 指標 (或任何自訂指標) 的最佳做法。如果分析供應商希望對自家服務新增 Core Web Vitals 支援，這份指南也能做為指引。

使用自訂指標或事件

如前所述，大部分的數據分析工具都可用來評估自訂資料。如果您的分析工具支援這項做法，因此，您應該使用這項機制的 Vitals 指標

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

定義或註冊編輯工具中的自訂指標 (如有需要)。(注意：並非全部分析服務供應商需要事先定義自訂指標)。
在前端 JavaScript 程式碼中計算指標值。
將指標值傳送至數據分析後端，確認名稱或 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 服務建立報表或資訊主頁，顯示收集到的值。

確保您符合建議的網站體驗核心指標門檻並在第 75 個百分位數顯示每項指標的值。

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

如果您的數據分析工具無法提供指標層級的報表資料根據預設，使用數據分析工具支援自訂維度。透過設定您追蹤的每個指標例項都屬於不重複自訂維度值您應該就能產生報表並按個別指標細分例項，前提是您必須在報表設定中加入自訂維度。每個執行個體都會有專屬的維度值，因此不會發生分組。

網站體驗指標報表就是這個技術使用 Google Analytics 的例子。程式碼是開放原始碼方便開發人員參考，做為本課程介紹的技術專區。

Web Vitals 的螢幕截圖
檢舉

在適當的時機傳送您的資料

網頁載入完畢後就能計算部分成效指標其他 (例如 CLS) 則考慮整個網頁的生命週期，最後，當頁面開始卸載時再進行一次

但這可能會發生問題，因為 beforeunload 和 unload 活動並不可靠 (尤其是行動裝置)，且使用時無法建議 (因為設定這類參數可能會導致網頁不適用「向前」快取)。

針對會追蹤網頁整個生命週期的指標，最好傳送指標目前的值是在 visibilitychange 事件期間，每當頁面的瀏覽權限狀態變更為 hidden這是因為網頁瀏覽權限狀態會變更為 hidden，但不保證該網頁能夠再次執行在行動裝置上，這一點尤其重要系統可在不發生任何網頁回呼的情況下關閉瀏覽器應用程式本身。

請注意，行動作業系統通常會觸發 visibilitychange 事件。這些動作也會在關閉分頁或瀏覽至visibilitychange 新網頁如此一來，visibilitychange 事件的可靠性遠高於 unload 或 beforeunload 事件。

由於部分瀏覽器錯誤，在少數情況下，visibilitychange 事件無法觸發。如果您要建立自己的數據分析資料庫，請務必留意這些錯誤。請注意，web-vitals JavaScript 程式庫已計算所有這些錯誤。

持續監控成效變化

更新 Analytics 導入設定，網站體驗核心指標指標的下一步是追蹤網站更新長期下來對成效的影響

版本變更

追蹤變更的一個單純 (且最終不可靠) 的方法就是變更實際工作環境的所有指標，並假設在部署日期對應新網站和部署日期會對應至舊的協作平台。不過所有因素 (包括在 HTTP、Service Worker 或 CDN 層執行快取) 可避免這項作業工作。

更好的做法是為每個部署的變更建立專屬版本使用數據分析工具追蹤該版本大部分數據分析工具都支援以及設定版本如果沒有，您可以建立自訂維度新增至部署版本

執行實驗

您還可以追蹤多個版本 (或

如果數據分析工具允許您定義實驗群組，請使用該功能；反之，您可以運用自訂維度確保每個指標值可與報表中的某個實驗群組建立關聯。

在數據分析進行實驗後對部分使用者進行實驗，然後比較控制組使用者的效能變化相信改變確實能提升成效，並所有使用者。

確保評估結果不會影響成效

評估實際使用者的成效時，務必確保任何您運作的成效評估程式碼不會對以及您網頁成效的部分如果答案為是，那麼您嘗試得出任何結論因此，您一定不需要永遠不知道數據分析程式碼是否在可能會產生負面影響

在自己的機器上部署 RUM 分析程式碼時，請務必遵循這些原則製作網站：

延後數據分析

Analytics 程式碼應一律以非同步、非封鎖的方式載入，且通常應該最後載入如果您在以免對 LCP 造成負面影響

具體來說，用來評估 Core Web Vitals 指標的所有 API 專為非同步和延遲載入指令碼而設計 (透過 buffered 標記)，因此您不需要急著立即載入指令碼。

如果評估的指標之後無法計算，網頁載入時間軸，建議您「只」內嵌需要提早執行的程式碼加到文件的 <head> 中 (因此不是禁止轉譯) ) 並延遲其餘部分。建議您不要載入所有數據分析只會因為一項指標才有需求

不要建立長時間的工作

Analytics 程式碼經常會在回應使用者輸入時執行，但如果您的 Analytics 程式碼進行大量的 DOM 測量，或使用其他處理器的 API Analytics 程式碼本身可能會導致輸入回應速度過慢。此外，如果包含分析程式碼的 JavaScript 檔案很大，正在執行該檔案可能會封鎖主執行緒，並對網頁的與下一個顯示的內容互動 (INP) 造成負面影響。

使用非阻塞 API

API，例如 sendBeacon() 和 requestIdleCallback() 專為執行非重要工作而設計並且封鎖使用者重要工作

這些 API 非常適合用於 RUM 數據分析資料庫的工具。

一般而言，所有數據分析信標都應使用 sendBeacon() API 傳送 (如果有的話)，所有被動分析評估程式碼都應在閒置期間。

不要追蹤過多資訊

瀏覽器公開大量成效資料不代表一定要錄下節目，並傳給數據分析伺服器

例如 Resource Timing API 可為網頁上載入的每個資源提供詳細的時間資料。然而，這些資料不一定都完全或提高資源負載效能

簡而言之，不要只追蹤資料，因為請確保資料能使用再使用資源追蹤