開始評估 Web Vitals

Katie Hempenius
Katie Hempenius

收集網站的網站體驗核心指標資料,是改善這些指標的第一步。全面的分析會從實際環境和實驗室環境收集效能資料。評估 Web Vitals 只需稍微修改程式碼,而且可以使用免費工具完成。

實際使用者監控 (RUM) 資料,又稱為欄位資料,可擷取網站實際使用者體驗到的效能。Google 會使用 RUM 資料,判斷網站是否符合建議的網站使用體驗核心指標門檻

如果您尚未設定 RUM,以下工具可快速提供網站實際效能資料。這些工具都採用相同的基礎資料集 (Chrome 使用者體驗報告),但用途略有不同:

  • Chrome 開發人員工具會在「效能」面板的即時指標檢視畫面中,整合 CrUX 資料集。您可以比較本機體驗與同一頁面上的實際使用者體驗,進而做出更明智的決定,決定要將偵錯工作重點放在哪裡。如要透過單一動作開始評估及改善網站的 Core Web Vitals,建議使用 Chrome 開發人員工具的「效能」面板。
  • PageSpeed Insights (PSI) 會回報過去 28 天內網頁層級和網域層級的匯總成效。此外,系統也會提供改善成效的建議。PSI 可在網路上使用,也可做為API使用。
  • Search Console 會針對每個網頁回報成效資料。因此,這項指標非常適合用來找出需要改善的特定網頁。與 PageSpeed Insights 不同,Search Console 報表會納入歷來成效資料。Search Console 只能用於您擁有且已驗證擁有權的網站。
  • CrUX 資訊主頁是預先建構的資訊主頁,可顯示您所選來源的 CrUX 資料。這項服務是建構在數據分析之上,設定程序大約需要一分鐘。與 PageSpeed Insights 和 Search Console 相比,CrUX 資訊主頁報表包含更多維度,例如資料可依裝置和連線類型細分。

值得一提的是,雖然先前列出的工具非常適合用於「開始」評估網站體驗核心指標,但在其他情況下也能派上用場。特別是 CrUX 和 PSI 都提供 API,可用於建立資訊主頁和其他報表。

收集 RUM 資料

雖然以 CrUX 為基礎的工具是調查 Web Vitals 效能的好起點,但我們強烈建議您搭配使用自己的 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 JavaScript 程式庫收集 Web Vitals 評估資料。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 AnalyticsGoogle 代碼管理工具

如果您已經有偏好的報表工具,不妨考慮使用該工具。如果沒有,您可以使用免費的 Google Analytics 來達成這項目標。

在考慮要使用哪項工具時,請考慮誰需要存取資料。當整間公司 (而非單一部門) 都想改善成效時,企業通常能獲得最佳成效。請參閱「跨部門修正網站速度」,瞭解如何爭取不同部門的支持。

資料解讀

分析成效資料時,請務必留意分布的尾端。RUM 資料經常顯示效能有很大差異,有些使用者體驗速度快,有些則速度緩慢。不過,使用中位數來總結資料可能會掩蓋這項行為。

就 Web Vitals 而言,Google 會根據「良好」體驗的百分比,而非中位數或平均值等統計資料,判斷網站或網頁是否符合建議的閾值。具體來說,網站或網頁必須達到 Core Web Vitals 門檻,75% 的網頁瀏覽量應達到各項指標的「良好」門檻。

使用實驗室資料評估網站體驗指標

實驗室資料 (也稱為合成資料) 是指在受控環境中收集的資料,而非實際使用者產生的資料。與 RUM 資料不同,實驗室資料可從預先發布環境收集,因此可納入開發人員工作流程和持續整合程序。Lighthouse 和 WebPageTest 就是收集合成資料的工具。

注意事項

RUM 資料和實驗室資料之間的差異總是存在的,尤其是實驗室環境的網路狀況、裝置類型或位置與使用者環境有顯著差異時。不過,如果要收集有關網站體驗核心指標的實驗室資料,請務必注意以下幾點:

  • 最大內容繪製時間 (LCP)在實驗室環境中測量時,可能會與在實地環境中使用 RUM 資料測量時的結果不同,原因可能是載入網頁的延遲 (透過重新導向、連線至伺服器的延遲或未快取的資料)、不同使用者看到的內容因螢幕而異,或是其他原因 (包括 Cookie 橫幅、個人化)。
  • 在實驗室環境中測量的累積版面配置位移 (CLS) 可能會人為地低於 RUM 資料中觀察到的 CLS。許多實驗室工具只會載入網頁,不會與網頁互動。因此,它們只會擷取初始網頁載入期間發生的版面配置轉移。相較之下,RUM 工具評估的 CLS 會擷取網頁整個生命週期內發生的意外版面配置位移
  • Interaction to Next Paint (INP) 需要使用者與網頁互動,因此無法在實驗室環境中進行測量。因此,總封鎖時間 (TBT) 是建議的 INP 實驗室代理值。TBT 會測量「首次顯示內容所需時間 (FCP) 和互動準備時間 (TTI) 之間的總時長,在此期間系統會封鎖網頁,不回應使用者輸入內容」。雖然 INP 和 TBT 的計算方式不同,但兩者都反映了引導程序期間遭到封鎖的主執行緒。主執行緒遭到阻斷時,瀏覽器會延遲回應使用者互動。

工具

您可以使用下列工具收集網站體驗核心指標的實驗室測量結果:

  • Chrome 開發人員工具會在「效能」面板的即時指標檢視畫面中,評估及回報特定網頁的網站使用體驗核心指標。這個檢視畫面可在開發人員變更程式碼時,即時提供成效意見回饋。
  • Lighthouse 會針對 LCP、CLS 和 TBT 產生報表,並強調可改善的效能。Lighthouse 可在 Chrome 開發人員工具中以 npm 套件的形式使用,也可以使用 Lighthouse CI 納入持續整合工作流程。
  • WebPageTest 會在標準報表中納入 Web Vitals。WebPageTest 可用於在特定裝置和網路條件下收集網站體驗核心指標資訊。