收集網站的 Web Vitals 資料是改善這些指標的第一步。全方位的分析會收集實際環境和實驗室環境的效能資料。評估 Web Vitals 只需要稍微修改程式碼，而且可以使用免費工具完成。
使用 RUM 資料評估網站體驗指標
實際使用者監控 (RUM) 資料 (又稱欄位資料) 會擷取網站實際使用者的效能體驗。Google 會根據 RUM 資料，判斷網站是否符合建議的網站使用體驗核心指標門檻。
開始使用
如果沒有 RUM 設定，下列工具會快速提供網站實際效能的資料。這些工具都採用相同的基礎資料集 (Chrome 使用者體驗報告)，但適用於略有不同的用途：
- Chrome 開發人員工具會整合 CrUX 資料集，並在「效能」面板的即時指標檢視畫面中顯示。比較本機體驗與同一網頁上的實際使用者體驗，有助於您做出更明智的決策，決定要將偵錯工作重心放在何處。如要開始評估及改善網站的 Web Vitals，建議使用 Chrome 開發人員工具的「效能」面板。
- PageSpeed Insights (PSI) 會提供過去 28 天的網頁層級和來源層級匯總成效報表。此外，還會提供成效提升建議。PSI 可在網頁上使用，也能以 API 形式提供。
- Search Console 會提供各網頁的成效資料。因此非常適合找出需要改進的特定網頁。與 PageSpeed Insights 不同，Search Console 報表包含歷來成效資料。您只能將 Search Console 用於自己擁有且已驗證擁有權的網站。
- CrUX Vis 是預先建構的資訊主頁，可顯示您所選網址或來源的 Chrome 使用者體驗報告歷來資料 (如有)。這項工具是以 CrUX 歷史記錄 API 為基礎建構而成，設定程序大約需要一分鐘。與 PageSpeed Insights 和 Search Console 相比，CrUX Vis 包含更多資料，例如最大內容繪製 (LCP) 子部分和導覽類型等。
- CrUX Vis 是一個歷史記錄資訊主頁，可顯示您所選來源或網址的 CrUX 資料。這項 API 是以 CrUX 記錄 API 為基礎建構而成，相較於 PageSpeed Insights 和 Search Console，CrUX Vis 報告包含更多詳細資料，例如 CrUX Vis 提供導覽類型和 LCP 與 RTT 資料。
請注意，雖然先前列出的工具非常適合用來「開始」評估網站體驗核心指標，但這些工具在其他情況下也很有用。特別是 CrUX 和 PSI 都提供 API，可用於建構資訊主頁和其他報表。
收集 RUM 資料
雖然以 CrUX 為基礎的工具是調查網站體驗核心指標成效的好起點，但我們強烈建議您搭配使用自己的 RUM。自行收集的 RUM 資料可提供更詳細且即時的網站效能意見回饋。方便您找出問題並測試可能的解決方案。
您可以透過專用的 RUM 供應商收集自己的 RUM 資料，也可以自行設定工具。
專屬 RUM 供應商專門收集及回報 RUM 資料。如要透過這些服務使用 Core Web Vitals，請洽詢 RUM 供應商，瞭解如何為網站啟用 Core Web Vitals 監控功能。
如果沒有 RUM 供應商，您或許可以運用 web-vitals JavaScript 程式庫，擴充現有的數據分析設定，以便收集及回報這些指標。下文將詳細說明這個方法。
web-vitals JavaScript 程式庫
如果您要自行導入 RUM 設定來收集網頁指標，最簡單的方法是使用 web-vitals JavaScript 程式庫。web-vitals 是一個小巧的模組化程式庫 (約 2 KB)，提供便利的 API，可收集及回報各項可透過實際工作環境資料評估的網站體驗核心指標。
構成網站體驗指標的指標並非全數直接透過瀏覽器的內建效能 API 顯示，而是以這些 API 為基礎建構而成。舉例來說，累計版面配置位移 (CLS) 是使用 Layout Instability API 實作。使用 web-vitals 時，您不必自行導入這些指標，而且可確保收集到的資料符合各項指標的方法和最佳做法。
如要進一步瞭解如何導入 web-vitals，請參閱說明文件和「評估實際工作環境中網頁指標的最佳做法」指南。
資料匯總
請務必回報 web-vitals 收集的評估結果。如果系統測量了這項資料，但未回報，您就永遠不會看到。web-vitals文件包含範例，說明如何將資料傳送至一般 API 端點、Google Analytics 或 Google 代碼管理工具。
如果您已有愛用的報表工具，不妨繼續使用。如果沒有，Google Analytics 免費版就能派上用場。
考慮要使用哪項工具時，請先想想哪些人需要存取資料。通常來說，如果全公司 (而非單一部門) 都對提升成效感興趣，企業就能獲得最大的成效提升。如要瞭解如何取得各部門的認同，請參閱「跨職能修正網站速度」。
解讀資料
分析成效資料時，請務必注意分配情形的尾端。RUM 資料通常會顯示效能差異很大，有些使用者體驗快速，有些則緩慢。不過，使用中位數來彙整資料可能會掩蓋這種行為。
就 Web Vitals 而言，Google 會使用「良好」體驗的百分比，而非中位數或平均值等統計資料，判斷網站或網頁是否符合建議的門檻。具體來說，如要讓網站或網頁達到網站體驗核心指標的門檻，75% 的網頁瀏覽次數必須達到各項指標的「良好」門檻。
使用實驗室資料評估網站體驗指標
實驗室資料 (又稱合成資料) 是從受控環境收集而來，而非來自實際使用者。與 RUM 資料不同，實驗室資料可從預先發布環境收集，因此可納入開發人員工作流程和持續整合程序。Lighthouse 和 WebPageTest 等工具會收集合成資料。
注意事項
RUM 資料和實驗室資料之間一定會有差異，特別是當實驗室環境的網路狀況、裝置類型或位置與使用者有顯著差異時。不過，在收集網站體驗核心指標的實驗室資料時，有幾項重要事項需要注意：
- 最大內容繪製 (LCP)是在實驗室環境中測得，與使用 RUM 資料在實際環境中測得的結果可能不同，原因包括網頁載入延遲 (透過重新導向、連線至伺服器的延遲時間或未快取的資料)、根據螢幕向不同使用者顯示不同內容，或其他原因 (包括 Cookie 通知橫幅、個人化)。
- 在實驗室環境中測得的累計版面配置位移 (CLS)，可能比 RUM 資料中觀察到的 CLS 低。許多實驗室工具只會載入網頁，不會與網頁互動。因此，這類事件只會擷取初始頁面載入期間發生的版面配置轉移。相較之下，RUM 工具測量的 CLS 會擷取網頁整個生命週期發生的非預期版面配置位移。
- 與下一個顯示的內容互動 (INP) 指標需要使用者與網頁互動，因此無法在實驗室環境中測量。因此，建議您使用總封鎖時間 (TBT) 做為實驗室 INP 的替代指標。TBT 測量的是「首次顯示內容所需時間和互動準備時間之間，網頁無法回應使用者輸入內容的總時長」。雖然 INP 和 TBT 的計算方式不同，但兩者都反映了啟動程序期間遭到封鎖的主要執行緒。主執行緒遭到封鎖時，瀏覽器會延遲回應使用者互動。
工具
您可以使用這些工具收集網站體驗核心指標的實驗室評估結果：
- Chrome 開發人員工具會在「效能」面板的即時指標檢視畫面中，評估及回報特定網頁的網站使用體驗核心指標。開發人員在變更程式碼時，可透過這個檢視畫面即時取得效能意見回饋。
- Lighthouse：Lighthouse 會產生 LCP、CLS 和 TBT 報表，並標示出可能的成效改善項目。Lighthouse 可在 Chrome 開發人員工具中以 npm 套件的形式使用，也可以透過 Lighthouse CI 併入持續整合工作流程。
- WebPageTest 的標準報表會納入 Web Vitals。WebPageTest 可用於在特定裝置和網路條件下收集網站體驗核心指標的資訊。