想要改善網站的 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 資訊主頁是預先建立的資訊主頁，可顯示所選來源的 CrUX 資料。這項服務是以 Data Studio 為基礎建構，設定程序大約需要一分鐘。與 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 程式庫，擴充現有的 Analytics 設定，收集並回報這些指標。下方將詳細說明這個方法。
Web-Vitals JavaScript 程式庫
如果您要為 Web Vitals 導入自訂 RUM 設定，最簡單的 Web Vitals 評估方式，就是使用 web-vitals JavaScript 程式庫。web-vitals 是一個小型模組化程式庫 (約 2 KB)，提供方便的 API，可收集及回報每項可透過網站收集資料的 Web Vitals 指標。
組成 Web Vitals 的指標並非全部由瀏覽器內建的效能 API 直接公開，而是建構在這些 API 之上。舉例來說，累計版面配置位移 (CLS) 是使用 Layout Instability API 導入。使用 web-vitals 後，您就不必自行實作這些指標；此外，您收集的資料也能符合各指標的做法和最佳做法。
如要進一步瞭解如何導入 web-vitals，請參閱說明文件和評估 Web Vitals 的最佳做法指南。
資料匯總
請務必回報 web-vitals 收集到的評估資料。如果這項資料已評估完成，但沒有顯示在報表上，您就無法查看。web-vitals 說明文件包含範例，說明如何將資料傳送至通用 API 端點、Google Analytics 或 Google 代碼管理工具。
如果您已經有偏好的報表工具，不妨考慮使用該工具。如果沒有，您可以使用免費的 Google Analytics 來達成這項目標。
考慮要使用何種工具時，最好思考哪些人需要存取資料。當整間公司 (而非單一部門) 都想改善成效時，企業通常能獲得最佳成效。請參閱「修正跨部門網站速度」，瞭解如何獲得各部門的認同。
資料解讀
分析成效資料時，請務必留意分布的尾端。RUM 資料經常顯示效能有很大差異，有些使用者體驗速度很快，有些使用者體驗速度很慢。不過，使用中位數匯總資料可能會掩蓋這項行為。
就網站體驗指標而言，Google 是以「良好」體驗的百分比來判斷網站或網頁是否符合建議門檻，而非採用「中位數」或「平均值」等統計資料。具體來說，如果網站或網頁符合 Core Web Vitals 指標的門檻，有 75% 的網頁造訪次數應符合各項指標的「良好」門檻。
使用實驗室資料評估網站體驗指標
實驗室資料 (也稱為合成資料) 是指在受控環境中收集的資料，而非實際使用者所產生的資料。實驗室資料與 RUM 資料不同，可從預先發布環境收集，因此可納入開發人員工作流程和持續整合程序。Lighthouse 和 WebPageTest 就是收集合成資料的工具。
注意事項
RUM 資料和實驗室資料之間的差異總是存在的，尤其是實驗室環境的網路狀況、裝置類型或位置與使用者環境有顯著差異時。不過，如果要收集有關網站體驗指標的實驗室資料，請務必注意以下幾點：
- 最大內容繪製 (LCP) 在實驗室環境中測量時，可能會與在實地環境中使用 RUM 資料測量時的結果不同，原因可能是網頁載入延遲 (透過重新導向、連線至伺服器的延遲或未快取的資料)、不同使用者看到的內容因螢幕而異，或是其他原因 (包括 Cookie 橫幅、個人化)。
- 在實驗室環境中測量的累積版面配置位移 (CLS) 可能會人為地低於 RUM 資料中觀察到的 CLS。許多實驗室工具只會載入網頁，不會與網頁互動。因此，它們只會擷取初始網頁載入期間發生的版面配置轉移。相較之下，RUM 工具評估的 CLS 會擷取網頁整個生命週期內發生的非預期版面配置位移。
- 無法在研究室環境中評估與下一個繪製動作 (INP) 的互動，因為這個方式需要使用者與網頁互動。因此，總封鎖時間 (TBT) 是建議的 INP 實驗室代理值。TBT 會評估「首次顯示內容所需時間」和「多久開始顯示網頁回應使用者輸入內容」之間的總時間長度。雖然 INP 和 TBT 的計算方式不同，但兩者都反映了引導程序期間遭到封鎖的主執行緒。當主執行緒遭到封鎖時，瀏覽器會延遲回應使用者互動行為。
工具
以下工具可用來收集 Web Vitals 的研究室測量結果：
- Chrome 開發人員工具會在「效能」面板的即時指標檢視畫面中，評估及回報特定網頁的 Core Web Vitals。這個檢視畫面可在開發人員修改程式碼時，提供即時效能意見回饋。
- Lighthouse 會提供 LCP、CLS 和 TBT 的報表，並強調可行的效能改善方式。Lighthouse 可在 Chrome 開發人員工具中以 npm 套件的形式使用，也可以使用 Lighthouse CI 納入持續整合工作流程。
- WebPageTest 會在標準報表中納入 Web Vitals。WebPageTest 可用於在特定裝置和網路條件下收集網站體驗核心指標資訊。