Core Web Vitals 是什麼？從 GSC 看懂 LCP、INP、CLS 數據與修復優先順序

Core Web Vitals 是 Google 在 2020 年推出的三項使用者體驗指標，分別是 LCP（最大內容繪製）、INP（互動到下次繪製）和 CLS（累計版面配置位移）。這三個數字不是速度分數，而是問題分布的分類依據。本文從 Google Search Console 報表的讀法出發，說明如何在診斷工具之間切換、處理資料不足的情況，並建立可操作的修復優先順序。

Core Web Vitals 是什麼：先看三個指標，不要先看總分

Core Web Vitals 衡量真實使用者頁面體驗的三個維度：主要內容出現的速度（LCP）、使用者操作後頁面的回應速度（INP）、頁面視覺是否穩定不跳動（CLS）。

這三項指標來自 Chrome 瀏覽器收集的真實使用者資料（CrUX），而不是單次測速的實驗數據。因此，它們在 Google Search Console 報表中呈現的是某段時間內真實訪客的體驗分布，而不是某次測量的瞬間分數。Google 在 Search Central 的官方說明中表示，改善核心網頁指標有助於提供更好的使用者體驗。

GSC 的 Core Web Vitals 報表把 URL 分成三種狀態：不良（Poor）、需要改善（Needs improvement）、良好（Good）。站長應該把這份報表當作問題分布的地圖，而不是單一分數的排行榜。

FID（首次輸入延遲）在 2024 年 3 月已正式從核心指標中移除，被 INP 取代。如果看到仍然提及 FID 的資料，那是過時的資訊。

LCP、INP、CLS 門檻表：哪些數字算好，哪些需要處理

三個指標各自有獨立的門檻，單位也不同。以下是 Google 定義的分類標準，數值來自 web.dev 的 Core Web Vitals 說明頁：

這三個門檻是 Google 根據真實使用者資料與 UX 研究設定的分類依據，達到 Good 不等於排名會提升，但持續落在 Poor 區間代表有可改善的體驗問題。

每個指標的判定依據是頁面上第 75 個百分位數的 Chrome 使用者資料。也就是說，如果你的 LCP 是 3.0 秒，代表 75% 的使用者載入最大內容需要超過 3.0 秒，而不是「某次測速得到的 3.0 秒」。

GSC 的 Core Web Vitals 報表怎麼讀

GSC 報表的入口在「體驗 > 網站體驗核心指標」。報表會分別顯示行動版和桌機版的 URL 狀況，以及每個狀態的 URL 數量。

報表的核心邏輯是：根據 CrUX 資料，把你的網址分類到「不良」「需要改善」「良好」三個桶子。如果一個 URL 的 field data 樣本不足，它不會出現在報表中，而不是被標記為不良。

點進「不良」的 URL 組後，你會看到 GSC 把相似的問題頁面歸成一組（URL group）。這個分組依據通常是 URL 模板，例如所有文章頁、所有產品分類頁，或者所有含特定參數的動態 URL。如何操作 GSC 的基礎介面，可以參考 GSC 成效與體驗報表的基本操作。

報表刷新週期大約是 28 天的滾動視窗。修復之後，GSC 的不良 URL 數量不會立刻歸零，因為 CrUX 需要累積足夠的真實使用者資料才會更新分類狀態。

GSC 不顯示即時分數，它顯示的是過去 28 天累積的真實 Chrome 使用者體驗分布。

為什麼 GSC、PageSpeed Insights、Lighthouse 分數會不同

GSC、PSI、Lighthouse 三個工具使用不同的資料來源，各自適合回答不同的診斷問題；把它們互相比較來找「哪個正確」是常見的誤用方式。

PSI 顯示 field data 和 lab data 兩段，這兩段數字可以不同。Field data 反映真實使用者體驗，lab data 反映 Lighthouse 在特定測試環境下的執行結果。Lighthouse 的測試是在 CPU 節流和網路模擬條件下進行的，因此數字會和真實使用者的環境有所差異。

如果你的 PSI field data 顯示 LCP 良好，但 Lighthouse lab data 的 LCP 很慢，代表你的測試環境條件比真實使用者更嚴苛，或者你的網站在慢速裝置上有問題但多數使用者裝置較快。這不一定是緊急問題，但值得記錄和追蹤。

GSC 和 PSI 的 field data 理論上應該接近，但 GSC 使用 28 天視窗，PSI 使用最近 28 天的 CrUX 月度資料，兩者的時間窗口略有不同，所以數字可以有輕微落差。

沒有足夠欄位資料時，該看 URL、Origin 還是 Lab Data

流量較少的頁面，例如新發布的文章或長尾產品頁，往往在 GSC 報表中看不到資料，也無法在 PSI 取得 field data。這不代表頁面沒問題，只代表 CrUX 樣本不足。

遇到這種情況，建議按以下三步驟處理：

1. 查看 Origin summary：在 PSI 輸入 URL 後，下方會顯示「Origin summary」，這是整個域名的 field data 彙總。資料來源是 Chrome UX Report（CrUX），每月更新一次，可作為整體域名體驗的參考基準，但不能代表特定 URL 的狀況。
2. 找 同模板的其他 URL：如果你的文章頁有 50 篇文章，其中 30 篇有 field data，那麼這 30 篇的 LCP 分布可以幫助你推測同模板頁面的效能範圍。
3. 跑 Lighthouse baseline：在修改之前先跑一次 Lighthouse，記錄基準值。修改後再跑一次，比較實驗性差異。這是資料不足時唯一可以立即操作的診斷路徑。

索引狀態也會影響資料可用性。如果一個 URL 沒有被收錄，它不可能在 CrUX 中累積足夠的資料。確認索引狀態可以參考 GSC 索引報表。

LCP 問題通常從哪裡開始查

LCP 計量的是頁面視窗中最大的內容元素出現的時間。這個元素通常是封面圖、文章標題背景圖、hero 區塊，或者大型段落文字。

在 PSI 的 Lighthouse 診斷中，點進「Largest Contentful Paint element」可以看到哪個 HTML 元素被記為 LCP 元素。知道是哪個元素之後，才能找到正確的優化方向。

內容站（文章頁、部落格）最常見的 LCP 問題來源：

• 首屏封面圖：圖片太大、格式不對、或者沒有設定 fetchpriority="high"
• 字型載入：使用 Google Fonts 但沒有 preconnect 或 font-display: swap
• 伺服器回應時間：TTFB（第一個位元組的時間）超過 800 毫秒，所有後續渲染都會延遲
• 阻塞資源：render-blocking JavaScript 或 CSS 放在 <head> 沒有 async/defer

LCP 的優化排序建議是：先確認 TTFB 正常，再確認 LCP 元素被提早載入，最後才處理 JavaScript 的渲染阻塞。如果 TTFB 超過 800 毫秒，其他優化的效果會打折扣。

INP 問題怎麼判斷：互動慢不等於頁面載入慢

INP（Interaction to Next Paint）取代 FID，成為目前核心互動體驗指標。FID 只測量第一次互動的輸入延遲，而 INP 測量頁面生命週期中所有互動（點擊、鍵盤輸入、觸控）的延遲，並取最壞的那次作為代表值。

INP 不良的症狀：使用者點了按鈕、輸入文字或選擇選項後，頁面「卡」了一下才更新畫面。這不是頁面載入慢的問題，而是 JavaScript 佔用主執行緒（main thread）太久，導致瀏覽器無法及時更新。

常見的 INP 問題來源：

• 點擊事件觸發了大量的 DOM 操作或重新渲染
• 使用了過多的第三方腳本，例如廣告、聊天機器人、行銷追蹤工具
• 在 JavaScript 的長任務（long task）中沒有 yield 讓瀏覽器處理互動事件

INP 的診斷可以用 Chrome DevTools 的 Performance 面板錄製互動過程，找出「Long Animation Frame」事件。這是工程層面的診斷工具，需要配合 DevTools，單靠 Lighthouse 或 PSI 看不到完整的互動流程。

重申：FID 是歷史資料，不是目前核心指標。如果你看到某篇文章把 FID 列為必追蹤的核心指標，那是 2024 年 3 月之前的資訊。

CLS 問題怎麼判斷：版面位移通常不是「速度慢」

CLS 記錄的是頁面載入過程中，不在使用者預期之內的版面位移量。它和 LCP 的「載入速度慢」完全不同，解決方法也完全不同。

CLS 的計算方式是：位移元素的可視範圍比例 x 位移距離比例。數字越高代表版面跳動越劇烈，0 是理想值，超過 0.1 就進入需要改善的區間，超過 0.25 是不良。

常見 CLS 問題的來源與檢查方式：

用 Chrome DevTools 的 Performance 面板可以直接看到哪些「Layout shift」事件發生，以及觸發位移的是哪個 DOM 元素。這是確定 CLS 根本原因最有效率的方法。

修復優先順序：先看 URL group，再看流量與模板覆蓋量

當多個 URL 同時有問題時，哪個先修？很多人的直覺是「修 PSI 分數最低的那個」，但這個邏輯在 SEO 效益上通常不是最佳解。

建議的排序框架：

1. 先確認是哪個 URL group 在 GSC 標記為 Poor：GSC 的 URL group 通常對應一個模板，修一個模板可以同時修復數十到數百個 URL。
2. 用 GA4 或 GSC 效能報表查那個模板的總點擊量：高流量的模板問題，對 SEO 整體影響最大。
3. 確認模板覆蓋多少 URL：如果這個問題影響 200 個文章頁，修一個模板可以解決 200 個問題；如果只影響 3 個頁面，投入產出比就低很多。
4. 評估修復難度：有些問題（例如加上 img width/height）實作時間短，可以先做；有些問題（例如重寫 JavaScript 渲染邏輯）複雜度高，需要排進工程規劃。

一個實用的排序公式（這是推論框架，不是 Google 的官方計算式）：

修復優先分數 = 問題嚴重度（Poor > Needs Improvement）x 受影響 URL 數量 x 該模板的月度自然流量 / 修復工時估計

這個排序讓你把有限的工程資源投入到對 SEO 和使用者體驗都最有回報的地方，而不是只靠 PSI 分數決定優先順序。修復之後如何追蹤排名變化，可以參考用 GSC 比較排名變化的方法。

修復應該以模板為單位，推到所有適用 URL 之後，才算完成一輪修復。零散地修單一 URL 在 GSC 報表上幾乎看不出整體改善，因為 URL group 的狀態是用組內多數 URL 的表現決定的。

Core Web Vitals 對 SEO 排名有多重要

Google 官方的說法（來源：Google Search Central，理解核心網頁指標與 Google 搜尋結果）是：「改善核心網頁指標有助於提供更好的使用者體驗，但內容的相關性仍然是搜尋結果排序的主要依據。」

這句話的事實部分：Google 確實把 CWV 納入頁面體驗訊號，CWV 是 Google 建議站長追蹤和改善的指標之一。

這句話的推論界線：把 CWV 從 Poor 改善到 Good，不保證排名上升；排名下降也不一定是 CWV 惡化導致的，需要和其他訊號一起分析。對這個問題有興趣可以看 SERP 結構與排名結果 的分析。

以下幾點是值得追蹤但不宜過度宣稱的範圍（均為推論，相關性存在，但因果方向不確定）：

• 持續在 Poor 狀態的頁面，可能在相同排名競爭中處於劣勢（推測，相關性不等於因果）
• 改善 CWV 有助於降低跳出率，使用者完成互動的比例可能提高（觀察值，因果待驗證）
• 提升頁面速度可能改善轉換數據，但這屬於 UX 影響，不是 Google 明確的排名訊號

CWV 改善後，自然流量是否有變化，建議同時用 GSC 效能報表和 自然流量數據 追蹤，而不是只看排名。

修復後如何驗證：field data 需要時間，lab data 可以即時看

修復程式碼並部署後，不要期待 GSC 隔天就從不良變成良好。Field data 需要 28 天累積才會完整反映新的使用者體驗狀況。

建議的驗證流程：

1. 部署後立刻在 PSI 上跑修復後的 URL，確認 Lighthouse lab data 有改善
2. 等待 7-14 天，再次查看 PSI 的 field data 是否有移動
3. 等待 28 天，在 GSC Core Web Vitals 報表中查看 URL group 狀態是否從 Poor 降到 Needs improvement 或 Good
4. 同時追蹤 GSC 效能報表的點擊、曝光、平均排名，確認改善 CWV 後的搜尋表現趨勢

GSC 有一個「驗證修復」（Validate fix）功能，可以在修復後主動通知 Google 重新評估。這個功能不會加速 CrUX 資料更新，但可以作為追蹤驗證進度的記錄工具。

FAQ：Core Web Vitals 常見判讀問題

Core Web Vitals 的三個指標是什麼？

目前核心指標為 LCP（最大內容繪製，衡量載入速度）、INP（互動到下次繪製，衡量互動回應速度）、CLS（累計版面配置位移，衡量視覺穩定性）。FID 已於 2024 年 3 月停用。

LCP 和 CLS 是什麼？

LCP 是頁面中最大的可視內容元素（通常是圖片或標題）出現所需的時間，門檻是 2.5 秒以內。CLS 是頁面載入過程中非預期版面位移的累計分數，門檻是 0.1 以內。

Core Web Vitals 還有影響 SEO 嗎？

Google 仍然把 CWV 列為頁面體驗訊號之一，建議改善。但改善後不保證排名提升；排名主要受內容相關性和其他搜尋意圖訊號影響。這是 Google 官方的說法，不是推測。

GSC 的 CWV 報表和 PageSpeed Insights 為什麼顯示不同結果？

GSC 和 PSI 的 field data 都來自 CrUX，但 GSC 使用 28 天滾動視窗，PSI 的時間窗口略有不同。此外，PSI 還會顯示 Lighthouse lab data，而 lab data 本來就和 field data 使用不同的測試條件，所以數字不同是正常現象。

修復後 GSC 多久才會更新？

Field data 需要 28 天累積。修復後建議先用 PSI 的 Lighthouse 確認 lab data 改善，等 7-14 天後看 PSI field data 的變化，28 天後才能在 GSC 報表中看到完整的群組狀態變化。

哪個工具可以測試 Core Web Vitals？

常用的組合是：Google Search Console（監控全站分布）、PageSpeed Insights（診斷單一 URL 的 field 和 lab 資料）、Chrome DevTools（工程診斷）、web.dev 提供的 Lighthouse 整合測試。對於沒有 CrUX 資料的低流量頁，只能依賴 lab data 做基準。

Core Web Vitals 和網站速度分數是一回事嗎？

不是。Lighthouse 的 Performance 分數（0-100）是綜合多個指標的加權分，而 Core Web Vitals 是三個獨立指標，各自有 Good / Needs Improvement / Poor 的分類。Performance 分數高不等於三個 CWV 都通過門檻；三個 CWV 都良好也不等於 Performance 分數一定高。