Core Web Vitals 是什麼：Google 怎麼量真實使用者體驗

Core Web Vitals 是 Google 用來量真實使用者體驗的三個指標

把一個頁面的 Lighthouse 跑到 92 分，然後打開 Search Console，看到的 Core Web Vitals 評級卻是 Needs Improvement。這個情況在台灣的網站專案裡相當常見，原因等一下說。

Core Web Vitals 是 Google 在 2020 年定義、2021 年正式納入排名信號的一組使用者體驗指標（想知道這個訊號實際上以多大的權重與時間延遲反映在 SEO 排名，可以延伸看CWV 對 SEO 排名的真實影響）。它包含三個子指標：LCP（最大內容繪製速度）、INP（互動到下一次繪製）、CLS（累積版面位移）。這三個指標不是 Google 隨便選的，它們是從大量真實使用者回饋資料中挑出來、最能預測使用者跳出行為的量測維度。

2024 年 3 月有一個重要的更新：FID（First Input Delay）被正式移除，由 INP 取代。這不是改名，而是重新定義了什麼叫「互動速度」，後面我會解釋為什麼 FID 量不到真正的問題。

如果你想了解 Core Web Vitals 之後該怎麼改，可以看 Core Web Vitals 優化的完整實戰方法，這篇先把三個指標是什麼、Google 怎麼評分的機制說清楚。更多背景可以參考 Google 官方 Core Web Vitals 指南。

三大指標各自測量什麼：LCP、INP、CLS 的技術定義

三個指標各自量的是不同的體驗維度。搞清楚每個指標的技術定義，才能理解為什麼某個頁面某個指標特別差。

LCP（Largest Contentful Paint）：最大元素畫完的時間

LCP 量的是從頁面開始載入，到視窗內最大的可見內容元素完成繪製的時間。最大元素通常是 hero image、H1 大字標題，或是一個大型的文字區塊，不一定是圖片。

有一個細節常被忽略：LCP 元素在頁面載入過程中可能會改變。一開始最大的元素可能是 H1，後來圖片載入完成，LCP 元素換成了圖片，瀏覽器會以最終確定的那個元素來計算時間。這也是為什麼 hero image 如果沒有加 fetchpriority="high"，LCP 很容易超標。

評分	LCP 時間
Good	低於 2.5 秒
Needs Improvement	2.5 到 4.0 秒
Poor	超過 4.0 秒

想深入了解 LCP 卡在哪裡、怎麼找出瓶頸，可以看 LCP 優化的具體技術方法。

INP（Interaction to Next Paint）：從點擊到畫面更新

INP 量的是使用者和頁面互動（點擊、鍵盤輸入、觸碰）之後，到瀏覽器完成下一次視覺更新的時間。它涵蓋三個階段：input delay（等待主線程空出來）、processing time（執行事件處理器）、presentation delay（繪製新畫面）。

INP 不只量第一次互動，而是在整個使用者造訪過程中追蹤所有互動，取第 75 百分位數作為這個頁面的 INP 分數。一個頁面的首次點擊可能很快，但翻頁、展開選單、篩選商品這些後續操作如果卡頓，INP 就會反映出來。

評分	INP 時間
Good	200 毫秒以下
Needs Improvement	200 到 500 毫秒
Poor	超過 500 毫秒

CLS（Cumulative Layout Shift）：版面意外位移的累積量

你在讀一篇文章，廣告圖片突然載入把內容往下推了半個畫面，手指已經點下去了，結果點到的是廣告。這就是 CLS（Cumulative Layout Shift） 要量的問題：頁面在載入過程中版面元素意外移動的累積程度。

每次版面位移的分數 = impact fraction（位移影響的畫面面積比例）× distance fraction（位移距離佔畫面高度的比例）。CLS 的計算方式在 2021 年有改過：現在用 session window 的最大值，不再累積整個頁面生命週期的所有位移，這解決了長時間停留的使用者分數被過度懲罰的問題。

評分	CLS 分數
Good	低於 0.1
Needs Improvement	0.1 到 0.25
Poor	超過 0.25

INP 為什麼在 2024 年取代 FID — 不只是換名字

很多文章把這件事寫成「FID 被廢棄，用 INP 替代」，然後就跳過了。但 FID 被移除是有技術原因的，而且那個原因告訴了你 INP 到底在量什麼不一樣的東西。

FID（First Input Delay）只量一件事：從使用者第一次點擊或觸碰，到瀏覽器開始回應這個事件的等待時間。注意，是「開始回應」的等待時間，不是整個互動完成的時間，也不包含事件處理器執行完的時間。

這有兩個根本的局限。第一，FID 只看第一次互動，後續的所有點擊它不管。一個頁面的首次點擊剛好很快（主線程那時候閒著），但用戶展開選單、篩選清單、提交表單時都卡住，FID 給出的是 Good，但使用者體驗其實很差。第二，FID 不量 processing time，也不量畫面更新，一個事件觸發後要執行 300ms 的 JavaScript 再更新畫面，FID 看不到。

INP 改用 Event Timing API，追蹤整個使用者造訪過程中所有的互動事件，量的是從互動開始到下一次畫面更新的完整時間（包含 input delay、processing time、presentation delay），然後取 p75 作為頁面的 INP 分數。

一個實際的差距：某個電商網站的商品篩選功能每次點擊要執行 400ms 的 JS，FID 可能顯示 40ms（只量到了一次快速的初始點擊），INP 就會顯示 420ms，直接進 Needs Improvement。想了解怎麼修 INP 問題，可以參考 INP 的實際優化策略。

Google 怎麼替你的網站打 CWV 分數：CrUX 75th percentile 機制

這裡說明為什麼 Lighthouse 90 分但 Search Console 顯示 Needs Improvement 的問題。這兩個工具量的不是同一件事。

Google 的排名信號用的是 CrUX（Chrome User Experience Report）資料，不是 Lighthouse 分數。CrUX 收集的是真實 Chrome 使用者的瀏覽記錄，包含所有不同的裝置、網路速度、地理位置。

評分機制是取 p75（75th percentile）：把一個頁面在過去 28 天所有的訪問資料裡，依照 LCP 時間從快排到慢，取第 75 名的數值作為這個頁面的「LCP 分數」。換句話說，必須有 75% 的訪問記錄達到 Good 門檻，這個頁面的 LCP 才算 Good。

為什麼選 p75 而不是中位數（p50）？p50 代表一半的使用者體驗，忽略了另外一半體驗較差的人。但 p75 也不是 p90 或 p95，是因為後者對極端慢速網路環境過於敏感，一些遠端連線的特殊案例可能拖垮整個評分。p75 是一個在「覆蓋大多數使用者」和「避免極端值干擾」之間的工程取捨。

相較之下，Lighthouse（lab data）在你的機器上模擬一個特定的網路條件（通常是 Fast 3G 或 Broadband 設定）跑一次，它不知道你有多少訪客是用手機、用 4G、從南部縣市連線。根據 TWNIC 2024 年台灣網路報告，94.9% 的台灣網路使用者會透過手機上網。行動裝置的 LCP 通常比桌機環境慢 1-2 秒，這就是 lab data 和 field data 分數常常對不上的主要原因。

另一個需要注意的點：CrUX 需要足夠的流量才能收集到資料。流量較低的頁面或新上線的頁面可能沒有 field data，Search Console 也不會顯示 CWV 評分，這時候只能靠 Lighthouse 的 lab data 作參考。

想自己驗證資格門檻，或想用 CrUX API 直接撈 p75 數值，可以參考 CrUX 數據查詢的五個入口，裡面把五種查詢方式跟資格門檻對照表都整理好了。

如何查看自己網站的 Core Web Vitals 分數

三個工具各有用途，場景不同選不同的工具。

PageSpeed Insights — 查單頁即時分數

打開 pagespeed.web.dev，輸入 URL 就可以看結果。報告分兩個區塊：上方是 Field Data（CrUX 資料，有的話），下方是 Lab Data（Lighthouse 模擬）。

Field Data 才是 Google 用來評分排名的依據。如果頁面流量不足，上方的 Field Data 區塊會顯示「沒有足夠的資料」，這時候只能看 Lab Data。注意不要把 Lighthouse Performance Score（0-100 的那個圓形數字）和 Core Web Vitals 評分混為一談，它們是不同的評估框架。

如果你在用 PSI 時發現分數每次跑都不一樣，或是 Desktop 和 Mobile 差距很大，PSI 分數波動原因與 Lab Data vs Field Data 的詳細解析裡有 Lighthouse 加權算法和 CPU 節流機制的完整說明。

Google Search Console — 查整站趨勢

Search Console 左側選「體驗」→「網站使用體驗核心指標」，可以看到整個網站依 Good / Needs Improvement / Poor 分群的 URL 數量，以及趨勢圖。

這裡用的是 CrUX field data，而且 Google 把相似的 URL 群組化（例如所有商品頁面會合併評估），所以你看到的是頁面類型的整體狀況，不是每個 URL 的獨立分數。修一個頁面類型可能會影響整群的評級。更多工具使用說明可以參考 Search Console Core Web Vitals 報告說明。

Web Vitals Chrome Extension — 邊瀏覽邊看

從 Chrome 網上應用程式商店安裝「Web Vitals」擴充功能，開啟後在每個頁面的右下角會即時顯示 LCP、INP、CLS 的 field data 數值（有 CrUX 資料的話）。適合開發過程中快速確認，不需要每次都開 PageSpeed Insights 跑一輪。

三個指標的評分門檻：什麼叫達標、什麼叫需要改善

把門檻數字整理在一起，方便對照：

指標	Good	Needs Improvement	Poor
LCP	低於 2.5 秒	2.5 到 4.0 秒	超過 4.0 秒
INP	200 毫秒以下	200 到 500 毫秒	超過 500 毫秒
CLS	低於 0.1	0.1 到 0.25	超過 0.25

一個頁面要被 Google 標記為「通過 Core Web Vitals 評估」，三個指標全部都要達到 Good。只要有一個落在 Needs Improvement 或 Poor，整個頁面的 CWV 評級就跟著降。

這裡有一個常見的誤解值得說一下：Core Web Vitals 是排名因素之一，但不是唯一的因素，也不是決定性的因素。Google 的官方說法是，CWV 是「tiebreaker」性質，當內容品質相近時才會有明顯影響。把一個 CWV Poor 的頁面改到 Good，不代表排名馬上飛衝，但把 Needs Improvement 的指標維持在邊緣也確實會拖累整體。

修哪個指標優先？一般來說 LCP 的影響範圍最廣，而且通常改起來比 INP 直覺。CLS 問題找到根源通常好修，但找根源需要在開發環境複現位移事件。INP 的問題最難診斷，因為它跟 JavaScript 執行的主線程佔用有關。

常見問題

Core Web Vitals 會影響 SEO 排名多少？

Google 把 CWV 定位成「tiebreaker」性質的排名信號，意思是當兩個頁面的內容品質接近時，CWV 表現更好的頁面可能會排在前面。它不是壓倒性的排名因素，不會讓一個內容很差的頁面因為 LCP 優秀就大幅提升排名。但反過來，一個原本排在好位置的頁面如果 CWV 長期是 Poor，累積下來會有影響。

Lighthouse 跑出 90 分，為什麼 Search Console 顯示 Needs Improvement？

因為它們量的不是同一件事。Lighthouse 是 lab data，在模擬的網路條件下跑一次。Search Console 顯示的是 CrUX field data，也就是真實 Chrome 使用者的瀏覽資料，涵蓋所有不同的裝置和網路速度。台灣 94.9% 的使用者會用行動裝置上網，行動裝置的 LCP 通常比桌機環境慢，這就是落差的主要來源。

我的網站流量很少，沒有 CrUX 資料怎麼辦？

CrUX 有最低流量門檻，低流量頁面或新上線的網站可能沒有 field data。這時候 Google 不會用 CWV 評分你的排名，也不會在 Search Console 顯示這個頁面的 CWV 狀態。你能做的是以 Lighthouse lab data 作為參考基準，把 LCP、TBT（Total Blocking Time）這些指標盡量優化，等流量上來後 CrUX 才會開始累積資料。

FID 跟 INP 的分數可以直接換算嗎？

不能換算。FID 和 INP 量的是不同的東西：FID 只量第一次互動的 input delay 部分，INP 量的是所有互動的完整互動時間（input delay + processing time + presentation delay），並取 p75。一個 FID Good（<100ms）的頁面，INP 可能是 Needs Improvement 甚至 Poor，因為後續互動的 processing time 才是真正的瓶頸。

行動版和桌機版的 CWV 分數是分開計算的嗎？

是的，Google Search Console 和 PageSpeed Insights 都會分開顯示行動版和桌機版的 CWV 分數。CrUX 資料依裝置類型分組，行動裝置的分數通常比桌機差，因為行動裝置的 CPU 較弱、網路條件較不穩定。

Core Web Vitals 達標了排名一定會進步嗎？

不一定。CWV 是排名因素，但排名是由很多信號共同決定的。把 CWV 從 Poor 改到 Good，移除了一個負面信號，但不代表其他排名因素也跟著提升。更常見的情況是：CWV 改善後，直接的使用者行為指標（停留時間、跳出率）有改善，這會間接影響排名。

如何知道哪個頁面的 CWV 最需要優先修復？

打開 Search Console 的「網站使用體驗核心指標」報告，它會把 Poor 的 URL 群組列在最上面，並顯示受影響的 URL 數量。優先修流量最高的 Poor 頁面。如果 Poor 頁面很多且屬於同一個模板（例如所有商品頁面），修模板就能一次解決整群。

CWV 的門檻值會再改變嗎？

有可能。Google 有說過 CWV 的門檻值會根據整體網路技術的進步和使用者期待的變化做調整。INP 在 2024 年才取代 FID，表示 Google 願意在量測方法上做根本性的修改。目前 LCP 2.5s、INP 200ms、CLS 0.1 是 2026 年現行標準，但追蹤 web.dev 的更新會是個好習慣。