結合使用 Google 工具，有效稽核、改善及監控網站。
發布日期：2020 年 5 月 28 日
網站使用體驗核心指標是一組指標，可根據載入效能、對使用者輸入內容的回應速度，以及版面配置穩定性等條件評估使用者體驗。
本指南將探討改善網站 Core Web Vitals 的工作流程，但工作流程的起點取決於您是否自行收集現場資料。最終要使用哪些 Google 工具診斷及修正使用者體驗問題，則取決於您的需求。
最好在實際環境中評估網站體驗核心指標
網站使用體驗核心指標專門用於評估使用者體驗，是以使用者為中心的指標。Lighthouse 等實驗室工具是診斷工具，可突顯潛在效能問題和最佳做法。實驗室工具是在預先定義的特定條件下執行，可能無法反映使用者實際體驗的網站體驗核心指標。
舉例來說，Lighthouse 是一種以實驗室為基礎的工具，會在模擬的電腦或行動環境中執行測試，並模擬節流。雖然這類模擬較慢網路和裝置狀況有助於診斷效能問題，但這只是網路狀況和裝置功能多樣性的一小部分，因此可能無法反映網站使用者的實際體驗。
Lighthouse 等實驗室工具通常也會以全新訪客的身分「冷載入」網頁。這通常是最慢的載入速度，但實際上，訪客如果先前造訪過網站，或是在網站上瀏覽，可能會有部分資產已快取。新訪客和工具也可能會因為 Cookie 通知或其他內容，而有不同的網站體驗。
簡而言之，雖然實驗室工具可指出潛在的效能問題，並協助您偵錯及疊代，但可能無法反映實際造訪網站的使用者人數。使用實際資料評估實際效能，並運用 Lighthouse 等實驗室工具診斷效能，瞭解如何改善。另請參閱「何時使用 Lighthouse」一節。
Google 會透過 Chrome 使用者體驗報告 (CrUX) 評估網站使用體驗核心指標。這份公開資料集是從實際 Chrome 使用者收集而來。許多 Google 和第三方工具都會使用這項資料，回報網站的 Core Web Vitals。
不過，CrUX 也有其限制。通常可以告訴您何時發生問題，但往往沒有足夠的資料告訴您原因。
盡可能收集自己的現場資料
如要改善網站的實際成效，最佳資料集就是您建立的資料集。首先，您要向網站訪客收集欄位資料。具體做法取決於貴機構的規模，以及您是否要付費使用第三方解決方案或自行建立解決方案。
付費解決方案幾乎一定會評估網站使用體驗核心指標 (和其他成效指標)，而且通常會提供各種工具，方便您深入瞭解結果資料。對於資源充足的大型機構來說，這可能是較好的方法。
不過，您可能不屬於大型機構，甚至沒有能力負擔第三方解決方案。在這些情況下，Google 的 web-vitals程式庫可協助您收集所有網頁指標。但您必須負責回報、儲存及分析這些資料。
如果您已使用 Google Analytics，但尚未開始收集自己的欄位資料，或許可以利用 web-vitals 程式庫將在欄位中收集的網站體驗指標傳送至 Google Analytics，並使用 Google Analytics 4 的 BigQuery 匯出功能產生資料報表。
瞭解 Google 工具
無論您是否自行收集現場資料，都可以使用多種 Google 工具分析網站使用體驗核心指標。建立工作流程前，先瞭解各項工具的概況，有助於判斷哪些工具最適合自己。
Chrome 使用者體驗報告 (CrUX)
如先前所述，CrUX 是公開資料集，內含從數百萬個網站部分真實 Google Chrome 使用者收集的現場資料。包括網站體驗核心指標，以及流量充足的網站的其他指標。
Chrome 使用者體驗報告提供每月BigQuery 資料集 (以來源為單位)，或每日 API (以網址或來源為單位)，前提是網址或來源在 Chrome 使用者體驗報告資料集中有足夠的樣本。您可以透過各種 CrUX 工具存取 CrUX 資料，包括程式輔助存取和供使用者使用的視覺化工具。
何時使用 CrUX
即使您自行收集現場資料，CrUX 仍有其用處。雖然 CrUX 代表的是部分 Chrome 使用者，但比較網站的現場資料與 CrUX 資料，有助於瞭解兩者是否一致。每種方式各有優缺點，可能導致結果有所差異。如果網站沒有任何欄位資料，只要網站出現在 Chrome 使用者體驗報告的資料集中，這份報告就能提供非常實用的高階總覽。
您可以直接使用 CrUX，也可以使用其他工具 (包括下文提及的工具)。直接使用 CrUX 資料集 (透過 BigQuery 或 API) 有助於顯示其他工具未提供的資料，例如其他工具通常不會顯示國家/地區層級的資料，或是查看 CrUX 中的其他指標，這些指標通常也不會顯示在其他工具中。
「不」適合使用 CrUX 的時機
CrUX 只會代表 Chrome 使用者，而且僅限部分 Chrome 使用者。完整的 RUM 解決方案可涵蓋 Chrome 和其他瀏覽器支援網站體驗核心指標的更多體驗。
如果網站流量不足，就不會出現在 Chrome 使用者體驗報告資料集中。如果您的網站屬於這種情況，就無法使用 CrUX，因此需要自行收集實際工作環境資料，瞭解網站在實際工作環境中的成效。或者，您必須依賴實驗室資料，但如先前所述，這類資料可能無法代表實際情況。
由於 Chrome 使用者體驗報告提供的資料是過去 28 天的移動平均值，因此不適合在開發期間使用，因為改善項目需要一段時間才會反映在 Chrome 使用者體驗資料集中。
最後，由於 CrUX 是公開資料集，因此可提供的資訊量和查詢資料的方式都有限。擷取自己的 RUM 資料可收集更多詳細資料 (例如 LCP 元素)，並進一步區隔資料來找出問題。登入使用者與登出使用者相比，網站使用體驗核心指標是更好還是更差？LCP 速度緩慢的使用者是否具有特定 LCP 元素？哪些互動導致 FID 和 INP 值偏高？
PageSpeed Insights (PSI)
PSI 這項工具會針對特定網頁，回報 CrUX 的現場資料和 Lighthouse 的實驗室資料。詳情請參閱各節。
使用 PSI 的時機
PSI 非常適合評估網頁或來源層級的 CrUX 效能，適用於行動版和電腦版使用者。這項工具很適合用來初步瞭解網頁或網站的網站體驗核心指標。您也可以查看競爭對手等其他網站的網站體驗核心指標資料。
如果指標一致，PSI 也會提供 Lighthouse 資料，其中包含改善網站體驗核心指標的實用建議。如果兩者不一致，Lighthouse 建議可能就比較不相關。
由於 Lighthouse 是從伺服器執行，因此與從開發人員工具執行 Lighthouse 相比，可形成更一致的基準。
「不」適合使用 PageSpeed Insights 的時機
PSI 僅適用於公開網址，無法用於無法公開存取的開發網站。
網站必須符合特定資格條件 (包括網站熱門程度門檻)，才能取得 Chrome 使用者體驗報告資料。如果網頁或來源沒有 Chrome 使用者體驗報告資料，PSI 就比較不實用，因為在這種情況下，PSI 只能顯示 Lighthouse 實驗室資料。
同樣地，如果您只有來源層級的 CrUX 資料，而非要測試的特定網址，這也會限制將來源層級的現場資料與網頁層級的實驗室診斷結果相互對照的實用性。擁有來源層級的欄位資料仍非常實用，可做為網站效能的摘要，Lighthouse 稽核或許也有幫助，但此時應格外謹慎。
最後，如果 CrUX 提供網頁層級資料，但與 Lighthouse 實驗室資料不同，Lighthouse 的建議可能價值有限。特別是載入後 CLS 問題，以及互動性網站體驗核心指標 (首次輸入延遲時間和互動性)，實驗室型稽核的用處較小。
Search Console
Search Console 會評估網站的搜尋流量和成效，包括網站使用體驗核心指標。只有確認網站擁有權的網站擁有者才能使用這項功能。
Search Console 的實用功能之一，就是會將類似的網頁 (例如使用相同範本的網頁) 分組，並進行單一評估。Search Console 也提供網站使用體驗核心指標報告，其中包含 CrUX 的現場資料。
何時該使用 Search Console
開發人員和非開發人員都能使用 Search Console，以其他 Google 工具無法提供的方式評估搜尋和網頁成效。這項工具會呈現 CrUX 資料，並依相似度將網頁分組，提供新穎的洞察資料，瞭解效能改善對整個網頁類別的影響。
「不」適合使用 Search Console 的時機
如果專案使用其他第三方工具，並依相似度將網頁分組，或是網站未納入 Chrome 使用者體驗資料集，可能就不適合使用 Search Console。
如果群組中的範例網頁與群組其餘網頁的特徵不同，網頁分組也可能造成混淆。舉例來說，如果群組整體未通過特定網站使用體驗核心指標，但範例網頁似乎都通過相同的網站使用體驗核心指標，就可能發生這種情況。如果群組包含長尾或很少造訪的網頁，載入速度可能會較慢，因為這些網頁較少快取。如果長尾中這類網頁的數量充足，可能會影響群組的整體通過率。
燈塔
Lighthouse 是一項實驗室工具，可提供具體的網頁效能改善機會。開發人員也可以透過 Lighthouse 使用者流程，編寫互動流程的指令碼，以便測試網頁載入以外的效能。
Lighthouse-CI 是相關工具，可在專案建構和部署期間執行 Lighthouse，協助進行效能迴歸測試。這項功能會顯示 Lighthouse 報表和提取要求，並追蹤一段時間內的效能指標。
使用 Lighthouse 的時機
在開發期間，無論是本機或暫存環境，Lighthouse 都是尋找效能改善機會的絕佳工具。同樣地，在建構及部署至暫存和實際工作環境的階段，Lighthouse CI 也很有用，因為需要進行效能迴歸測試，才能維持良好的使用者體驗。
「不」適合使用 Lighthouse 的時機
Lighthouse (或 Lighthouse CI) 無法取代實際工作環境資料。Lighthouse 主要是一種診斷工具，會列出預先定義的網頁載入作業可能發生的問題和最佳做法。系統顯示的建議不一定與使用者的實際體驗相符。
雖然 Lighthouse 可透過 PageSpeed Insights 等工具診斷正式網站，但最好是在開發和持續整合環境中使用 Lighthouse，在效能問題進入正式環境前就加以解決。
您也可以透過 Chrome 開發人員工具「效能」面板中的「深入分析」功能，取得 Lighthouse 提供的稽核結果，進一步分析網頁效能。
Chrome 開發人員工具的「效能」面板
Chrome 開發人員工具是一組瀏覽器內建的開發工具，包括「效能」面板。「效能」面板是實驗室工具，包含兩種「模式」：
首次開啟「效能」面板時，「即時指標」畫面會提供目前的網站體驗核心指標，並可從 CrUX 匯入現場資料。與網頁互動時，您可以透過這項功能「即時」查看效能，嘗試找出效能問題，特別是 CLS 和 INP 指標顯示的載入後問題。
其次，開發人員可使用「效能」面板，擷取網頁載入期間或記錄時間範圍內所有網頁活動的設定檔 (或追蹤記錄)。這個檢視畫面會深入分析觀察到的所有內容，包括網路、算繪、繪製和指令碼活動等層面，以及網頁的 Core Web Vitals。此外，這項工具還會提供與 Lighthouse 類似的深入分析。
何時使用「效能」面板
開發人員應使用「效能」面板，深入瞭解特定網頁的效能。
您可以使用即時指標檢視畫面，快速瞭解網頁目前的效能特徵，並在與網頁互動時找出潛在問題。
追蹤記錄檢視畫面特別適合用於偵錯影響 INP 的回應性問題。一旦找出回應不佳的互動並可重複執行，效能面板就能提供大量資料，說明瀏覽器中發生的情況，協助您瞭解問題，包括主執行緒封鎖、JavaScript 呼叫堆疊和算繪作業。
「不」適合使用「效能」面板的時機
「效能」面板是開發人員工具，主要提供實驗室資料，但也會提供來自 CrUX 的部分現場環境資訊。這無法取代實際資料。
追蹤記錄檢視畫面包含許多偵錯資訊，但對於新手開發人員或非開發人員來說，可能難以理解。不過，面板開啟時顯示的即時指標檢視畫面，提供更易於使用的介面，可滿足不需要完整詳細資料的使用者需求。
三步驟工作流程，確保網站的網站體驗核心指標維持良好狀態
改善使用者體驗時，最好將這個過程視為持續循環。如要改善 Core Web Vitals 和其他效能指標，可以採取以下做法：
- 評估網站健康狀態並找出痛點。
- 偵錯並進行最佳化。
- 使用持續整合工具監控，以偵測及避免迴歸。
步驟 1：評估網站健康狀態，找出可改善之處
建議您先從欄位資料著手，評估網站健康狀態。
- 使用 PageSpeed Insights 查看來源的整體網站使用體驗核心指標，以及個別網址的具體資訊。
- Search Console 的網頁分組功能可有效運作，有助於找出需要改善的網頁。
- 如果您有 RUM 資料，通常這是找出有問題的特定網頁或流量區隔的最佳方式。
無論是分析自行收集的欄位資料還是 CrUX 資料，這個步驟都至關重要。如果沒有收集現場資料，只要網站出現在資料集中，Chrome 使用者體驗報告資料就可能足以引導您。
使用 PageSpeed Insights 分析網站效能
PageSpeed Insights 會顯示過去 28 天的使用者體驗資料，並以第 75 百分位數呈現 CrUX 資料。也就是說，如果 75% 的使用者體驗符合特定指標的門檻，該體驗就會被視為「良好」。
如果您想查看特定網頁的成效，請使用該網頁。開始進行最佳化時，如要全面瞭解網站，建議先從首頁著手，因為首頁通常是許多網站上最熱門的頁面之一。
一開始請著重於 PSI 的「實際使用者體驗」部分。您最多會看到四種資料檢視畫面：輸入的網址和整個來源的行動版和電腦版。比較這些資料，看看兩者有何不同。行動裝置的效能通常不如桌機，因為行動裝置的資源較為有限，且可能在網路不穩定的情況下運作。如果網址和來源資料差異很大，請嘗試瞭解原因：首頁通常是使用者造訪的第一個頁面 (即到達網頁)，因此速度可能會比來源慢，因為來源使用者會受到未預先載入的瀏覽器快取影響。由於系統會快取所有共用資產，因此後續網頁的載入速度可能會更快，進而降低來源層級的匯總資料。
PSI 也會顯示所有三項 Core Web Vitals (LCP、CLS 和 INP)，以及診斷 TTFB 和 FCP 指標。是否有任何網站體驗核心指標未達標準，以及未達標準的程度？這會指出應將心力放在何處。
瞭解這些數字之間的關係，尤其是 LCP。如果 LCP 速度緩慢 (如本例所示)，請查看 TTFB 和 FCP，這兩者都是該指標的里程碑。在本例中，TTFB 為 1.8 秒，因此很難達到建議的 2.5 秒門檻，確保 LCP 良好。這表示後端速度緩慢 (伺服器問題或缺少 CDN)、網路速度緩慢，或是重新導向導致第一個 HTML 位元組延遲。詳情請參閱最佳化 TTFB 指南。FCP 則需要額外一秒，這可能再次表示網路速度較慢。在本例中，LCP 並未在 FCP 之後很久才發生，這表示網頁載入後，LCP 資源已獲得充分最佳化。此外，CrUX 現在也會在資源類型和子部分中顯示更多診斷資訊，協助您診斷 LCP 問題。
如果是 CLS，請查看 CrUX CLS 和 Lighthouse CLS 分數，判斷這是載入 CLS 問題 (Lighthouse 會偵測到並提供建議)，還是 Lighthouse 無法偵測到的載入後 CLS 問題。詳情請參閱最佳化 CLS 指南。
如要瞭解網頁的回應速度，請查看互動時延遲分數。查看 Lighthouse 中的 TBT 稽核，瞭解網頁初次載入時是否發生大量 JavaScript 處理作業，這可能會影響 INP。INP 是難以改善的指標，詳情請參閱最佳化 INP 指南。
在 Search Console 中找出成效不佳的網頁
如果您想測試特定網址或整個網站，PSI 很有用，但 Search Console 可協助您針對特定類型的網頁進行改善。如果許多網頁共用主題或技術，且 Search Console 能夠成功識別這些網頁，這項功能就特別實用。
Search Console 中的 Core Web Vitals 報告會顯示網站成效的整體情況，但您仍可深入瞭解需要注意的特定網頁。您也可以透過 Search Console 執行下列操作：
- 找出需要改善的個別網頁群組，以及提供良好使用者體驗的網頁群組。
- 取得網址的精細成效資料，並依狀態、指標和類似網頁群組 (例如電子商務網站上的產品詳細資料頁面) 分組。
- 取得詳細報表，其中會將行動裝置和電腦的網址歸入各個使用者體驗品質類別。
找出要查看的特定網頁後，即可如先前所述使用 PSI，進一步瞭解這些網頁的問題。
步驟 2：偵錯及最佳化
在步驟 1 中，您應該已找出需要提升效能的網頁，以及要改善的網站體驗核心指標。您可以透過 Google 工具取得更多資訊，瞭解根本原因並找出問題。
- 查看 Lighthouse 稽核，取得網頁的高階指引
- 使用效能面板的即時指標檢視畫面，即時分析網站使用體驗核心指標。
- 使用「效能」面板追蹤功能，偵錯效能問題並測試程式碼變更。
如需更詳細的指引，請參閱下列指南：
使用 Lighthouse 發掘商機
PageSpeed Insights 會為您執行 Lighthouse，您也可以從 Chrome 開發人員工具執行 Lighthouse，這有助於在本機驗證修正項目，但「效能」面板 (下一個主題) 是更全面的工具，可協助您在本機找出並修正效能問題。
重點是驗證 Lighthouse 稽核是否會重現您嘗試解決的問題 (例如 LCP 緩慢或 CLS 問題)。根據預設，Lighthouse 只會在網頁載入期間評估使用者體驗。由於這是實驗室工具，因此也會排除 INP，改用 TBT。
如果 Lighthouse 指標顯示的問題與您想解決的問題類似，稽核中的大量資訊就能協助您找出問題並建議解決方案。
您可以篩選稽核結果，只顯示感興趣的網站體驗核心指標，專注於修正與特定指標相關的問題：
如要瞭解 INP，請使用 TBT 稽核找出可能影響這些指標的問題，但請注意，如果沒有互動，Lighthouse 的診斷能力會受到限制。
使用 Chrome 開發人員工具的即時指標畫面進行即時分析
「效能」面板中的 Chrome 開發人員工具即時指標畫面，會在網頁載入期間和瀏覽網頁時，即時顯示網站使用體驗核心指標。因此，這項指標可以擷取 INP，以及載入後發生的版面配置變化。您也可以查看各項指標的詳細資訊：
這個檢視畫面提供許多實用資訊，有助於找出效能問題，甚至可以從 CrUX 提取欄位資訊。如要取得更多資訊，可以透過追蹤深入瞭解。
使用「效能」面板深入瞭解
您可以使用 Chrome 開發人員工具的「效能」面板，記錄一段時間內所有網頁行為的設定檔 (或追蹤記錄)。
您可以在「洞察」側邊面板中查看成效洞察資訊。如果適用，也會顯示網站體驗核心指標和這些指標的實際使用者資料值。
「版面配置轉移」軌跡會醒目顯示版面配置轉移，點選這些轉移可進一步瞭解轉移的元素，以便偵錯 CLS。
追蹤記錄底部的「時間軸」會顯示 LCP 等重要時間。按一下即可瞭解詳情。
火焰圖也會以紅色三角形標示長時間工作 (可能導致 INP 問題)。
這些功能以及效能面板其他部分的資訊，可協助您判斷修正項目是否對網頁的 Core Web Vitals 有任何影響。
在實際環境中偵錯網站體驗核心指標
實驗室工具不一定能找出影響使用者的所有 Core Web Vitals 問題原因。這也是為什麼收集自己的現場資料如此重要，因為現場資料會考量實驗室資料無法考量的因素。
詳情請參閱「在實際環境中偵錯效能」。
步驟 3：監控變更
修正問題後，請務必確認修正作業是否達到預期效果，以及新問題是否會影響網站體驗核心指標。這需要將效能問題監控納入開發人員工作流程，避免效能問題發布至正式環境，並定期監控欄位資料，確保效能正常。
在持續整合 (CI) 環境中監控效能需求
Lighthouse-CI 可讓您自動對程式碼提交內容執行 Lighthouse 稽核，防止效能迴歸問題進入程式碼。這項工具可檢查效能時間 (可能會有所變動)，或僅檢查效能稽核，做為 Lint 工具，避免程式碼出現不良做法。
使用欄位資料查看網站健康趨勢
雖然您應盡量在所有效能問題進入正式環境前找出並修正，但使用 RUM 監控實際工作環境資料，對於找出任何漏網之魚至關重要。市面上有很多商用 RUM 產品可協助您完成這項作業。web-vitals JavaScript 程式庫可自動收集網站的欄位資料，並視需要使用這些資料來支援自訂資訊主頁和警報系統。
如果網站沒有 RUM 解決方案，您可以使用各種 CrUX 工具，對實際工作環境資料進行基本趨勢分析。
結論
如要確保使用者享有快速且愉悅的體驗，您必須以效能為優先考量，並採用工作流程來確保進度。只要使用適當的工具和程序進行稽核、偵錯及監控，您就能打造優質的使用者體驗，並維持在網站體驗核心指標的良好門檻內。