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