改善網站體驗指標的第一步，就是收集網站的網站體驗指標資料。經過完善四捨五入的分析會從真實世界和研究室環境收集成效資料。如要評估網站體驗指標，您僅需進行少量程式碼變更，且可使用免費工具完成。
使用 RUM 資料評估網站體驗指標
實際使用者監控 (RUM) 資料又稱為現場資料，擷取網站實際使用者所體驗的效能。Google 會使用 RUM 資料來判斷網站是否符合建議的網站體驗核心指標門檻。
開始使用
如果您未設定 RUM，下列工具可快速提供網站實際成效的相關資料。這些工具都是根據相同的基礎資料集 (Chrome 使用者體驗報告) 建立，但用途略有不同：
- PageSpeed Insights (PSI)：PageSpeed Insights 會回報過去 28 天的網頁層級和來源層級成效匯總資料。此外，它還會提供提升成效的建議。如果只想評估一種操作，建議開始評估及改善網站的網站體驗指標，建議使用 PSI 稽核網站。您可以透過網頁版或 API 取得 PSI。
- Search Console：Search Console 會回報個別網頁的成效資料。這個方式也很適合用來找出需要改善的網頁。有別於 PageSpeed Insights，Search Console 報表會納入歷來成效資料。Search Console 只能用於你擁有且已驗證擁有權的網站。
- CrUX 資訊主頁：CrUX 資訊主頁是預先建立的資訊主頁，可顯示所選來源的 CrUX 資料。它以數據分析為基礎，這項程序大約需要一分鐘才能完成。與 PageSpeed Insights 和 Search Console 相比，CrUX 資訊主頁報表提供更多維度，例如可依裝置和連線類型細分資料。
值得注意的是，雖然上述工具非常適合用於評估網站體驗指標的「開始使用」，但在其他情況下也很有用。尤其是 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 是小型的模組化程式庫 (約 1 KB)，提供了簡便的 API，可收集和回報每個欄位評估的網站體驗指標指標。
構成網站體驗指標的指標並非完全由瀏覽器內建的 Performance API 提供，而是以這些指標為基礎。舉例來說，累計版面配置位移 (CLS) 會使用 Layout Instability API 實作。使用 web-vitals 時，您就不必自行導入這些指標，也可確保您收集的資料符合每項指標的方法和最佳做法。
如要進一步瞭解如何實作 web-vitals，請參閱說明文件和現場評估網站體驗指標的最佳做法指南。
資料匯總
請務必回報 web-vitals 收集的測量資料。如果這項資料已評估但未記錄，就不會看到。web-vitals 說明文件舉例說明如何將資料傳送至一般 API 端點、Google Analytics (分析) 或 Google 代碼管理工具。
如果您已經有慣用的報表工具，可以考慮採用。沒有的話，Google Analytics (分析) 完全免費。
考慮該使用何種工具時，建議您想想需要有誰能存取資料。一般來說，當整個公司 (而非單一部門) 都想改善成效時，企業的成效通常最為出色。請參閱「修正網站速度跨部門問題」一文，瞭解如何獲得不同部門的認同。
資料解讀
分析成效資料時，請務必留意分佈狀況的尾部。RUM 資料通常顯示出效能差異很大；有些使用者享有快速體驗，有些則是緩慢體驗。然而，使用中位數匯總資料很容易遮蓋這種行為。
瞭解網站體驗指標時，Google 會根據「良好」體驗的百分比 (而非統計資料中位數或平均值等統計資料)，判斷網站或網頁是否符合建議的門檻。具體來說，如果網站或網頁有 75% 的網頁造訪率達到各項指標的「良好」門檻，才算達到網站體驗核心指標門檻。
使用研究室資料評估網站體驗指標
研究室資料 (又稱為合成資料) 是從受管環境收集，而非實際使用者收集的資料。與 RUM 資料不同的是，我們可以從試產環境中收集研究室資料，因此會納入開發人員工作流程和持續整合程序。例如 Lighthouse 和 WebPageTest 等是收集綜合資料的工具。
注意事項
RUM 資料和研究室資料始終會存在差異，尤其是在研究室環境的網路條件、裝置類型或位置與使用者之間有極大差異時更是如此。不過，如要收集特別在網站體驗指標中的研究室資料，請留意以下幾個重點：
- 累計版面配置位移 (CLS)：在研究室環境中測量的「累計版面配置位移」可能會人為低於 RUM 資料中觀察到的 CLS。CLS 定義為「在網頁整個生命週期期間，發生的所有非預期版面配置位移總和，個別版面配置位移分數的總和」。不過，由於網頁是由實際使用者或綜合成效評估工具載入，因此網頁效期通常截然不同。許多研究室工具只會載入網頁，不會與頁面互動。因此只會擷取初次載入網頁期間發生的版面配置位移。相反地，RUM 工具測量的 CLS 會擷取網頁整個生命週期發生的非預期的版面配置位移。
- 首次輸入延遲時間 (FID)：在研究室環境中無法評估「首次輸入延遲時間」，因為這項功能需要使用者與網頁互動。因此，建議您使用「Total Blocking Time」(總封鎖時間) (TBT) 做為 FID 的研究室 Proxy。TBT 會評估「首次顯示內容所需時間和互動時間的總時間，期間網頁無法回應使用者輸入內容」作業。雖然 FID 和 TBT 的計算方式不同，但兩者都會在啟動程序期間反映遭封鎖的主要執行緒。主執行緒遭到封鎖時，瀏覽器會延遲回應使用者互動。FID 可用來評估使用者首次嘗試與網頁互動時發生的延遲時間 (如果有的話)。
工具
這些工具可用來收集網站體驗指標的研究室評估資料：
- 網站體驗指標 Chrome 擴充功能：網站體驗指標 Chrome 擴充功能會評估及回報特定網頁的網站體驗核心指標 (LCP、FID 和 CLS)。這項工具可以在開發人員變更程式碼時，提供即時效能意見回饋。
- Lighthouse：Lighthouse 回報 LCP、CLS 和 TBT 情形，並列出潛在效能改善項目。Lighthouse 在 Chrome 開發人員工具中可供 Chrome 擴充功能使用，也可以做為 npm 套件使用。Lighthouse 也可透過 Lighthouse CI，納入持續整合工作流程中。
- WebPageTest： WebPageTest 會在標準報表中納入 Web Vitals。WebPageTest 適合用於收集特定裝置和網路狀況下的網站體驗指標資訊。