如何使用目前的數據分析工具評估網站體驗指標。
能夠評估及回報網頁的實際成效，對於長期診斷及改善成效至關重要。如果沒有欄位資料，就無法確認你對網站所做的變更是否確實能達到預期的結果。
許多熱門的 實際使用者監控 (RUM) 分析服務供應商，已在其工具中支援 Core Web Vitals 指標 (以及許多其他 Web Vitals)。如果您目前使用其中一種 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 服務，然後建立報表或資訊主頁，顯示已收集到的值。
為確保符合建議 Core Web Vitals 的門檻，製作報表時需要在第 75 個百分位數顯示每個指標的值。
如果數據分析工具並未以內建功能提供量化報表，您仍可透過產生一份報表，列出所有指標值依遞增順序排序，您還是可以手動取得這項資料。產生此報表後，報表中有 75% 的完整、排序後清單，結果在該指標的第 75 個百分位數。無論您以何種方式 (依裝置類型、連線類型、國家/地區等) 區隔資料，結果都是這樣。
如果分析工具預設不會提供指標層級的報表細目，只要支援自訂維度，應該就能取得相同的結果。為您追蹤的每個指標執行個體設定專屬的自訂維度值後，如果您在報表設定中加入自訂維度，應該就能產生按個別指標例項細分的報表。由於每個例項都有專屬的維度值，因此系統不會進行分組。
網站重要指標報表就是使用 Google Analytics 的這項技術的範例。這份報告的程式碼為開放原始碼，開發人員可以參考這份報告，瞭解本節所述的技術。
在適當時間傳送資料
有些效能指標可在網頁載入完成後計算，其他指標 (例如 CLS) 則會考量網頁的整個生命週期，並在網頁開始卸載後才算出最終結果。
但這可能會造成問題，因為 beforeunload 和 unload 事件都不可靠 (尤其是行動裝置)，而且不建議使用，因為這兩個事件會讓網頁不符合使用往返快取的資格。
對於追蹤網頁整個生命週期的指標，建議您在 visibilitychange 事件中傳送指標的目前值，並在網頁的顯示狀態變更為 hidden 時傳送。這是因為一旦頁面的顯示狀態變更為 hidden，就無法保證該頁面上的任何指令碼能夠再次執行。這點在行動作業系統上尤其重要，因為瀏覽器應用程式本身可以關閉，而不會觸發任何頁面回呼。
請注意，行動作業系統在切換分頁、切換應用程式或本身關閉時，通常會觸發 visibilitychange 事件。關閉分頁或前往新頁面時，也會觸發 visibilitychange 事件。這使得 visibilitychange 事件比 unload 或 beforeunload 事件可靠得多。
長期監控成效
更新數據分析導入作業，以便追蹤及回報網站體驗核心指標，接下來請追蹤網站變更對長期效能造成的影響。
管理變更版本
追蹤變更的簡單 (但最終不可靠) 方法，就是將變更部署至實際環境，然後假設部署日期後收到的所有指標都對應至新網站，而部署日期前收到的所有指標則對應至舊網站。不過，許多因素 (包括在 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 會針對網頁載入的每個資源提供詳細的時間資料。不過，並非所有資料都會對改善資源載入效能有所幫助。
簡而言之，不要只因為資料存在就追蹤資料，請務必在使用追蹤資料的資源前，先確保資料會被使用。