如何使用目前的數據分析工具評估網站使用體驗指標。
能夠評估及回報網頁的實際成效，對於長期診斷及改善成效至關重要。沒有欄位資料，就無法確定你對網站所做的變更是否確實能達成預期的結果。
許多熱門的 實際使用者監控 (RUM) 分析服務供應商，已在其工具中支援 網站使用體驗核心指標 (以及許多其他網站使用體驗指標)。如果您目前使用其中一種 RUM 分析工具，就能評估網站上的網頁是否符合建議的 Core Web Vitals 門檻，並防止日後出現回歸現象。
雖然我們建議使用支援 Core Web Vitals 指標的數據分析工具，但如果您目前使用的數據分析工具不支援這些指標，不一定要切換。幾乎所有數據分析工具都提供方法，可用來定義及評估自訂指標或事件，也就是說，您很可能可以使用目前的數據分析供應商來評估核心網站體驗指標，並將這些指標加入現有的數據分析報表和資訊主頁。
本指南將說明使用第三方或自家分析工具評估 Core Web Vitals 指標 (或任何自訂指標) 的最佳做法。對於希望在服務中加入 Core Web Vitals 支援的數據分析供應商來說，這份指南也相當實用。
使用自訂指標或事件
如上所述，大多數分析工具都允許您評估自訂資料。如果您的數據分析工具支援這項功能，您應該就能使用這個機制評估每項 Core Web Vitals 指標。
在數據分析工具中評估自訂指標或事件通常分為三個步驟：
- 在工具的管理員頁面中定義或註冊自訂指標 (如有需要)。(注意：並非所有數據分析供應商都要求事先定義自訂指標。)
- 在前端 JavaScript 程式碼中計算指標的值。
- 將指標值傳送至 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 服務，然後建立報表或資訊主頁，顯示已收集到的值。
為確保您符合建議的網站使用體驗核心指標門檻，您需要在報表中顯示各指標的 75 百分位數值。
如果您的數據分析工具未提供內建的百分位數報表，您還是可以透過產生報表，手動取得每個指標值並以遞增順序排序。產生這份報表後，報表中所有值的完整排序清單中，75% 的結果就是該指標的 75 百分位數，無論您如何區隔資料 (依裝置類型、連線類型、國家/地區等) 都一樣。
如果您的數據分析工具預設不會提供指標層級報表細目，只要數據分析工具支援自訂維度，您應該就能取得相同的結果。只要為您追蹤的每個指標個別例項設定專屬的自訂維度值，即可產生報表，並依個別指標個別例項進行細分 (前提是您在報表設定中加入自訂維度)。由於每個例項都有專屬的維度值，因此系統不會進行分組。
網站重要指標報表就是使用 Google Analytics 的這項技術的範例。這份報告的程式碼為開放原始碼，開發人員可以參考這份報告，瞭解本節所述的技術。
在適當時間傳送資料
有些效能指標可在網頁載入完成後計算，其他指標 (例如 CLS) 則會考量網頁的整個生命週期，並在網頁開始卸載後才算出最終結果。
不過，由於 beforeunload 和 unload 事件都不可靠 (尤其是在行動裝置上)，因此不建議使用這類事件 (因為這可能會導致網頁無法使用往返快取)。
對於追蹤網頁整個生命週期的指標，建議您在 visibilitychange 事件中傳送指標的目前值，並在網頁的顯示狀態變更為 hidden 時傳送。這是因為一旦頁面的顯示狀態變更為 hidden，就無法保證該頁面上的任何指令碼能夠再次執行。這點在行動作業系統上尤其重要，因為瀏覽器應用程式本身可以關閉，而不會觸發任何頁面回呼。
請注意，行動作業系統通常會在切換分頁、切換應用程式或關閉瀏覽器應用程式時觸發 visibilitychange 事件。關閉分頁或前往新頁面時，也會觸發 visibilitychange 事件。這使得 visibilitychange 事件比 unload 或 beforeunload 事件可靠得多。
長期監控成效
更新數據分析導入作業，以便追蹤及回報網站體驗核心指標，接下來請追蹤網站變更對長期效能造成的影響。
管理變更版本
追蹤變更的簡單 (但最終不可靠) 方法，就是將變更部署至實際環境，然後假設部署日期後收到的所有指標都與新網站相符，而部署日期前收到的所有指標都與舊網站相符。不過，許多因素 (包括在 HTTP、服務工作者或 CDN 層級快取) 都可能導致這項功能無法運作。
更理想的做法是針對每個已部署的變更建立專屬版本，然後在數據分析工具中追蹤該版本。大多數的數據分析工具都支援設定版本。如果沒有，您可以建立自訂維度，並將該維度設為已部署的版本。
執行實驗
您可以同時追蹤多個版本 (或實驗)，進一步使用版本管理功能。
如果您可以使用數據分析工具定義實驗組，請使用這項功能。否則，您可以使用自訂維度，確保每個指標值都能與報表中的特定實驗群組相關聯。
在 Analytics 中設定實驗後，您就可以向部分使用者推出實驗變更，並比較該變更的成效與控制組使用者成效。一旦確信變更確實可改善成效，即可向所有使用者推出。
確保評估不會影響效能
在評估真實使用者的成效時，您執行的任何成效評估程式碼絕對不得對網頁成效造成負面影響。如果是這樣，您就無法得知成效對業務的影響，因此無法做出任何結論，因為您永遠無法確定是否是分析程式碼本身造成最大的負面影響。
在實際網站上部署 RUM 分析程式碼時，請務必遵循下列原則：
延後數據分析
Analytics 代碼一律應以非同步、非阻斷的方式載入，且通常應在最後載入。如果您以阻斷方式載入數據分析程式碼，可能會對 LCP 造成負面影響。
用於評估 Core Web Vitals 指標的所有 API 均專門設計用於支援非同步和延遲的指令碼載入作業 (透過 buffered 標記)，因此您不必急著提早載入指令碼。
如果您要評估的評估指標無法在網頁載入時間表的後續階段計算，請僅將需要提早執行的程式碼內嵌至文件的 <head> 中 (因此不會造成轉譯阻斷請求)，並延後執行其餘程式碼。請勿因為單一指標需要，就提早載入所有 Analytics。
請勿建立長時間的工作
Analytics 程式碼通常會在回應使用者輸入時執行，但如果 Analytics 程式碼執行大量 DOM 測量或使用其他耗用大量處理器的 API，Analytics 程式碼本身可能會導致輸入回應速度變慢。此外，如果包含分析程式碼的 JavaScript 檔案很大，執行該檔案可能會阻斷主執行緒，並對網頁的Interaction to Next Paint (INP) 造成負面影響。
使用非封鎖式 API
sendBeacon() 和 requestIdleCallback() 等 API 是專門用於執行非重要工作，且不會阻斷使用者重要工作的 API。
這些 API 是 RUM 分析程式庫中非常實用的工具。
一般來說，所有數據分析信標都應使用 sendBeacon() API (如有) 傳送，所有被動數據分析評估程式碼也應在閒置期間執行。
請勿追蹤不必要的資料
瀏覽器會提供大量效能資料，但即使資料可供使用，也不一定代表您應該記錄並傳送至數據分析伺服器。
舉例來說，Resource Timing API 會針對網頁載入的每個資源提供詳細的時間資料。不過，並非所有資料都會對改善資源載入效能有所幫助。
簡而言之，請勿只因資料存在而追蹤資料，請確保在耗用追蹤資料的資源前，先使用該資料。