搭配運用 Google 工具，有效稽核、改善及監控您的網站。
Core Web Vitals 是一組指標，用於根據載入效能、使用者輸入內容的回應速度和版面配置穩定性等條件評估使用者體驗。
本指南將深入探討改善網站 Core Web Vitals 的工作流程，但無論您是否收集自己的實際資料，工作流程的第一步都不同。應用程式至哪個部分，則取決於哪些 Google 工具適合診斷及修正使用者體驗問題。
Core Web Vitals 最適合用於評估
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 程式庫可協助您收集「所有」網站體驗指標。不過，您必須對資料的回報、儲存和分析方式負責。
如果您已使用 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 資訊主頁中查看 BigQuery 資料，讓網站查看網站的歷來趨勢。
使用 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「和」研究室的現場資料。如要瞭解詳情，請參閱個別部分。
使用 PSI 的時機
行動裝置和電腦使用者都能透過 PSI 評估網頁層級或來源的 CrUX 成效。建議您針對網頁或網站，初步瞭解 Core Web Vitals。你也可以透過這項工具，查看其他網站 (例如競爭者) 的 Core Web Vitals 資料。
PSI 也會提供 Lighthouse 資料，以便在指標一致的情況下提供實用建議，協助改善 Core Web Vitals。如果兩者無法保持一致，Lighthouse 建議的關聯性可能會降低。
Lighthouse 是由伺服器執行，因此與透過開發人員工具執行 Lighthouse 相比，基準組可能會更加一致的基準。
「不」使用 PSI 的時機
PSI 僅適用於公開網址。無法用於未公開存取的開發網站。
網站必須符合特定資格條件 (包括網站熱門程度門檻)，系統才會提供 CrUX 資料。如果沒有網頁或來源的 CrUX 資料，PSI 就較不實用，因為只有在這類情況下，PSI 才會顯示 Lighthouse 研究室資料。
同樣地，如果您只有來源層級的 CrUX 資料，而不是測試的特定網址，那麼也會限制將來源層級欄位資料與網頁層級的研究室診斷建立關聯的實用性。提供來源層級欄位資料仍非常實用，有助於掌握網站成效的摘要，Lighthouse 稽核也或許有幫助，但在這個情況下，應格外謹慎。
最後，CrUX 中會提供網頁層級資料，但與 Lighthouse 研究室的資料不同，Lighthouse 提供的建議價值可能有限。尤其是在載入 CLS 後的問題，以及互動 Core Web Vitals (FID 和 INP) 的互動中，以研究室為基礎的稽核較不實用。
Search Console
Search Console 會評估網站的搜尋流量和成效，包括 Core Web Vitals。只有確認網站擁有權的網站擁有者能夠使用這項工具。
Search Console 的一項重要功能，是將類似的網頁 (例如採用相同範本的網頁) 歸入單一群組評量。此外，Search Console 也會根據 CrUX 的實際欄位資料，提供「Core Web Vitals」報告。
使用 Search Console 的時機
Search Console 適合開發人員和非開發人員角色，非常適合使用其他 Google 工具無法評估搜尋和網頁成效。這份報告可呈現 CrUX 資料，並依相似度將頁面分組，有助您瞭解效能改善後對整個類別的網頁有什麼影響。
「不」使用 Search Console 的時機
如果專案使用不同的第三方工具 (依相似程度將頁面分組)，或者 CrUX 資料集中未顯示網站，則 Search Console 可能不適用 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 擴充功能是一項診斷工具，可在您瀏覽網站時，顯示 Core Web Vitals 指標。如果目前網頁的 CrUX 資料列於 CrUX 資料集內，則也會納入該資料的 CrUX 資料，並提供偵錯資訊，協助您找出 Core Web Vitals 效能問題。
使用 Web Vitals 擴充功能的時機
任何角色都能使用 Web Vitals 擴充功能，評估網頁生命週期中所有階段的 Core Web Vitals。非常適合做為「即時」查看成效，嘗試找出效能問題。尤其是載入後問題，尤其是與 CLS 和 INP 指標互動時可能遇到的問題。
不使用 Web Vitals 擴充功能的時機
Web Vitals 擴充功能並不是網頁效能的全方位評估。此外，報表顯示的指標與執行環境有極大差異，開發人員通常擁有能力較高的機器，或能存取速度較快的網路。
Chrome 開發人員工具的「Performance」面板
Chrome 開發人員工具是一組瀏覽器內開發工具，包括 Performance 面板。「效能」面板是一項研究室工具，可剖析網頁載入或記錄期間所有網頁活動。這項工具提供深入分析，能深入分析在網路、轉譯、繪製和指令碼活動等維度，以及網頁的 Core Web Vitals 資料。
使用效能面板的時機
開發人員在開發期間應使用效能面板，取得網頁效能的深入分析資訊。如要針對影響 FID 或 INP 的回覆問題偵錯，這種做法特別實用。找出並重複回應不良的互動後，效能面板就能提供豐富的資料，例如瀏覽器發生的情況，協助您瞭解問題，包括主執行緒封鎖、JavaScript 呼叫堆疊和轉譯工作。
「不」使用效能面板的時機
「效能」面板是只提供研究室資料的開發人員工具，不會取代欄位資料，這個檔案包含大量偵錯資訊，但因此，新手或非開發人員人員可能難以理解。
以下三個步驟的工作流程，可確保網站 Core Web Vitals 的健康狀態良好
努力改善使用者體驗時，建議您將這個過程視為一個持續的循環。如要改善 Core Web Vitals 和其他成效指標，建議採用下列其中一種做法：
- 評估網站健康狀態並找出問題點。
- 偵錯和最佳化。
- 使用持續整合工具監控，找出及避免迴歸問題。
步驟 1：評估網站健康狀態並找出待改善之處
建議先從現場資料著手，以評估網站健康狀態。
- 使用 PageSpeed Insights 查看來源網站體驗 Core Web Vitals 體驗的所有指標，以及個別網址的特定資訊。
- Search Console 可用來找出哪些網頁需要改善，確保網頁分組功能可為網站帶來良好成效。
- 如果您有 RUM 資料，那麼最好的方式通常是找出有問題的網頁或流量區隔。
無論您要分析自己收集的現場資料或 CrUX 資料，第一步都是很重要的。如果您未收集現場資料，那麼 CrUX 資料或許足以引導您。同樣地，只要在資料集中列出您的網站，即可參考這些資料。
使用 PageSpeed Insights 分析網站成效
PageSpeed Insights 會以第 75 個百分位數顯示過去 28 天的使用者體驗資料。也就是說，如果 75% 的使用者體驗符合特定指標設定的門檻，系統就會將體驗視為「良好」。
如果您想要查看特定網頁的成效，請使用該網頁。如果您想瞭解網站在第一次進行最佳化時的整體觀點，建議您先從首頁著手，因為首頁通常是許多網站上最熱門的網頁。
著重在 PSI 的「實際使用者遭遇的問題」一節。你最多會看到四種資料檢視畫面：輸入網址的行動裝置和電腦，以及完整來源。您可以比較兩者，看看兩者有何差異。行動裝置的效能通常不如電腦，因為這種裝置的資源有限，網路條件可能較不穩定。如果網址和來源資料有顯著差異，請試著釐清原因：首頁通常是使用者最先造訪的網頁 (也就是到達網頁)，所以可能比來源使用者完全忽略未經檢查的瀏覽器快取，慢慢處理速度。系統會快取所有共用資源，藉此減少匯總來源層級的資料，因此後續網頁的載入速度可能會更快。
PSI 還會顯示全部三項 Core Web Vitals (LCP、CLS 和 FID) 和待處理的 INP 指標，以及診斷 TTFB 和 FCP 指標。是否有任何 Core Web Vitals 的運作結果會失敗？這個問題的發生原因為何？這可指出該集中心力在哪些地方。
瞭解這些數字 (尤其是 LCP) 之間的關係。如果 LCP 比較慢 (如本例所示)，請查看 TTFB 和 FCP 這兩個指標的里程碑。這個範例中的 TTFB 為 1.8 秒，因此很難達到 2.5 秒可滿足 LCP 建議的門檻。這可能是後端速度緩慢 (伺服器問題或 CDN 欠缺)、網路速度較慢，或是重新導向延遲第一個 HTML 位元組。詳情請參閱將 TTFB 最佳化指南。而 FCP 又多了一秒，而這也表示網路速度較慢。以這個範例來說，LCP 不會太長，因為 FCP 表示網頁本身載入時，LCP 資源已經過最佳化處理。
就 CLS 而言，請查看 CrUX CLS 和 Lighthouse CLS 分數，確認這是載入 CLS 問題 (Lighthouse 會擷取並建議)，或者 Lighthouse 無法擷取的 CLS 問題。詳情請參閱最佳化 CLS 指南。
如需回應，請查看 FID 和 INP 分數。查看 Lighthouse 中的待定檢查，確認在初始網頁載入期間是否進行大量 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 稽核，取得頁面層級指南
- 使用 Web Vitals 擴充功能即時分析 Core Web Vitals。
- 使用 Chrome 開發人員工具的效能面板為效能問題偵錯，以及測試程式碼變更。
如需詳細指南，請參閱下列指南：
透過 Lighthouse 發掘商機
PageSpeed Insights 可為您執行 Lighthouse，但您也可以透過 Chrome 開發人員工具執行 Lighthouse，這有助於在本機驗證修正結果。
重點是驗證 Lighthouse 稽核是否確實重現了您想解決的問題 (例如 LCP 速度緩慢或 CLS 問題)。Lighthouse 預設只會評估網頁載入期間的使用者體驗，由於這是一項研究室工具，因此也排除 FID 和 INP，並改用 TBT。
當 Lighthouse 指標提出的問題與你要解決的問題相似時，稽核報告中的豐富資訊有助於找出問題並建議解決方案。
您可以篩選稽核項目，只顯示想查看的 Core Web Vitals 資料，集中查看特定指標相關問題的修正結果：
針對 FID 和 INP，請使用 TBT 稽核找出可能影響這些指標的問題，但請注意，Lighthouse 假如沒有互動，Lighthouse 的診斷結果有限。
透過 Web Vitals 擴充功能即時分析
Web Vitals Chrome 擴充功能會在載入網頁「和」瀏覽網頁時，即時顯示 Core Web Vitals。因此可以擷取 FID 和 INP，以及載入後發生的版面配置位移。偵錯選項會顯示每個指標的詳細資訊：
建議您將 Web Vitals 擴充功能視為檢查效能問題，而非全方位的偵錯工具，這是 Chrome 開發人員工具中的效能面板。
透過成效面板細查
Chrome 開發人員工具中的效能面板可剖析特定時間範圍內的所有頁面行為。
時間碼 (例如 LCP) 會顯示在 Timings 軌道中。點按下方按鈕即可瞭解詳情。
「Layout Shifts」追蹤會醒目顯示版面配置位移，按一下這些事件即可進一步瞭解哪些元素會移位 CLS 偵錯。
長 Tasks (可能衍生 FID 和 INP 問題) 也會以紅色三角形醒目顯示。
這些功能以及效能面板的其他部分的資訊，可協助您判斷修正結果是否會影響網頁的 Core Web Vitals。
對領域的 Core Web Vitals 進行偵錯
研究室工具不一定能找出所有影響使用者核心網站體驗指標問題的成因。這將說明研究室資料無法涵蓋的因素，所以收集自己的現場資料十分重要。
詳情請參閱欄位中的偵錯效能。
步驟 3：監控變更
修正問題後，請務必確保問題達到必要的影響，並確保新問題不會影響 Core Web Vitals。如此一來，開發人員工作流程中必須監控效能問題，以免發生效能問題。此外，請定期監控現場資料，確保達到這個目標。
監控持續整合 (CI) 環境中的效能要求
Lighthouse-CI 可讓您對程式碼修訂版本自動執行 Lighthouse 稽核，避免輸入程式碼時出現效能迴歸問題。檢查效能時間 (可能變動) 或僅檢查效能稽核，做為防止程式碼出現不良行為的檢查工具。
根據實際資料查看網站健康狀態趨勢
雖然您應設法找出並修正所有效能問題，才能正式發布，但使用 RUM 監控現場資料，是找出遺漏的問題。市面上有許多商業 RUM 產品可協助您完成這項工作。web-vitals JavaScript 程式庫可以自動收集網站的欄位，並視需要使用這些資料支援自訂資訊主頁和快訊系統。
針對沒有 RUM 解決方案的網站，您可以使用 CrUX 資訊主頁進行現場資料的基本趨勢分析。這項工具會針對 CrUX 中的網站回報下列內容：
- 網站總覽：可將 Core Web Vitals 劃分為電腦和行動裝置類型。
- 依指標類型區分的歷來趨勢：顯示各種每月 Chrome 使用者體驗報表資料的指標分佈情形。
- 使用者客層：顯示整個來源中，各個客層 (包括裝置和有效連線類型) 使用者網頁瀏覽量的分佈情形。
CrUX 資訊主頁是以 CrUX BigQuery 資料集為基礎，這個資料集每月更新一次。這項功能可提醒你定期查看 Core Web Vitals。
結論
想確保提供快速愉快的使用者體驗，關鍵在於以成效為優先，並採用工作流程來確保進步。只要使用合適的工具和程序稽核、偵錯及監控，就能打造良好的使用者體驗，同時讓效能維持在改善 Core Web Vitals 目標的門檻。