如何使用目前的數據分析工具評估網站體驗指標。
此外，能否評估網頁實際成效並製作報表，是長期診斷和改善效能的關鍵。如果沒有現場資料，就無從得知您對網站變更是否確實能達成預期結果。
許多熱門的實際使用者監控 (RUM) 分析供應商已開始在自家工具 (以及許多其他網站體驗指標) 中支援「網站體驗核心指標」指標。如果您正在使用這些 RUM 分析工具，可以先評估網站上的網頁是否符合建議的網站體驗核心指標門檻，並防止日後發生迴歸問題。
雖然我們建議使用支援 Core Web Vitals 指標的分析工具，但如果您使用的分析工具不支援這些指標，則不一定需要切換。幾乎所有數據分析工具都提供定義及評估自訂指標或事件的方法，這表示您可以使用目前的分析供應商評估 Core Web Vitals 指標，並將其新增至現有的數據分析報表和資訊主頁。
本指南說明使用第三方或內部分析工具評估網站體驗核心指標 (或任何自訂指標) 指標的最佳做法。對於希望為自家服務新增網站體驗核心指標支援的分析服務供應商，也可以參考這份文件。
使用自訂指標或事件
如上所述，大部分的分析工具都能用來評估自訂資料。如果您的分析工具支援這項功能，您應該就能利用這項機制評估每個 Core Web Vitals 指標。
使用分析工具評估自訂指標或事件時，通常分為三個步驟：
- 如有需要，請在工具的管理員中定義或註冊自訂指標。(注意：並非所有分析供應商都要求事先定義自訂指標。)
- 在前端 JavaScript 程式碼中計算指標值。
- 將指標值傳送至您的分析後端，確保名稱或 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) 則會考量網頁的整個生命週期，而且在頁面開始卸載後才會開始最終成效。
但這可能會發生問題，因為 beforeunload 和 unload 事件並不可靠 (特別是在行動裝置上)，而且不建議使用 (因為它們會導致網頁無法使用往返快取)。
對於追蹤網頁整個生命週期的指標，建議您在 visibilitychange 事件期間，每當頁面顯示狀態變更為 hidden 時，就傳送指標目前的值。這是因為一旦網頁的顯示設定狀態變更為 hidden，就無法保證該網頁上的所有指令碼都可以再次執行。在行動裝置作業系統上更是如此，因為瀏覽器應用程式本身可在不觸發任何網頁回呼的情況下關閉。
請注意，行動作業系統通常會在切換分頁、切換應用程式或關閉瀏覽器應用程式時觸發 visibilitychange 事件。而且會在關閉分頁或導覽至新頁面時觸發 visibilitychange 事件。因此，visibilitychange 事件比 unload 或 beforeunload 事件可靠。
持續監控成效
更新分析實作方式，以便追蹤網站體驗核心指標指標並製作報表後，下一步就是追蹤網站變更對效能的影響。
版本變更
一種簡單 (且終極不可靠) 追蹤變更的方法，是將變更部署到實際工作環境，然後假設部署日期後收到的所有指標都會對應到新站，而部署日期前收到的所有指標都會對應到舊網站。但是，任意數量的因素 (包括在 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 會針對您網頁上載入的每個資源提供詳細時間資料。 但是，在改善資源載入效能的情況下，不太可能讓這些資料都不一定有用或有用。
簡而言之，不要只因為記錄資料而追蹤資料，請在使用資源追蹤之前確認資料使用方式。