Core Web Vitals 是什麼？三大指標拆開講，搞懂它才能真的影響 Google 排名
重點整理
- Core Web Vitals 由三個指標組成：LCP（載入速度）、INP（互動回應）、CLS（版面穩定性），全部都有具體的數字門檻
- 這三個指標自 2021 年起已正式納入 Google 排名訊號，2024 年 INP 正式取代舊的 FID
- 指標不達標不代表一定排不上去，但在其他條件相近時，體驗分數高的頁面會獲得優勢
到底什麼是 Core Web Vitals
簡單說，Core Web Vitals 是 Google 設計的一組「使用者體驗量尺」，目的是把「這個頁面好不好用」這件主觀的事，轉換成可以量測的數字。
類比一下：就像餐廳評分可以拆成出餐速度、服務態度、環境整潔三個維度打分，Core Web Vitals 也是把「網頁體驗」拆成三個可量化的面向，分別衡量載入、互動、穩定性。
Google 官方把這組指標定位為 Page Experience 訊號的核心，並且每年都可能調整組成——2024 年就發生了一次重大更換：原本的 FID（首次輸入延遲）被 INP 取代。所以這不是死的規格，要定期追蹤。
三個指標，各管一件事
LCP：最大內容繪製（Largest Contentful Paint）
頁面上「最大可見元素」載入完成的時間點。這個元素通常是主視覺圖片、Hero Banner、或一大塊文字區塊。
標準：
- ✅ 好：2.5 秒以內
- ⚠️ 需改善：2.5 到 4.0 秒
- ❌ 差：超過 4.0 秒
最常見的問題來源：圖片沒壓縮、沒設 preload、伺服器 TTFB 太慢、或 render-blocking 的 CSS/JS 擋住了主要內容。
假設你現在有一個賣手工皂的網站，首頁一進去就是一張 3MB 的產品大圖，那個圖就是 LCP 元素，載入慢了就直接拉低分數。
INP：互動到下一次繪製（Interaction to Next Paint）
2024 年 3 月正式取代 FID 的新指標。它量測的是「使用者點擊或輸入之後，頁面多快給出視覺回應」，而且是取整個瀏覽過程中最差的那幾次互動來計算，比舊的 FID 嚴格很多。
標準：
- ✅ 好：200 毫秒以內
- ⚠️ 需改善：200 到 500 毫秒
- ❌ 差：超過 500 毫秒
常見問題：JavaScript 主執行緒被塞住、第三方外掛（聊天機器人、廣告腳本）佔資源、React/Vue 渲染更新過重。
CLS：累計版面位移（Cumulative Layout Shift）
頁面元素在載入過程中突然跑位的程度。你一定遇過這種狀況：正要點一個按鈕，廣告突然跑出來，你結果按到廣告——這就是高 CLS 造成的體驗。
標準：
- ✅ 好：0.1 以下
- ⚠️ 需改善：0.1 到 0.25
- ❌ 差：超過 0.25
常見原因：圖片或影片沒有設定固定的寬高比、字型載入時的 FOUT 造成文字跳動、動態插入的橫幅廣告、或非同步載入的 UI 元件沒有保留佔位空間。
這跟 Google 排名的關係，到底有多直接
Google 官方的說法是：Core Web Vitals 是排名因素之一，但不是最重要的那個。內容相關性、E-E-A-T、反向連結這些還是更核心。
但這裡有個重要的「但是」：
當兩個頁面的內容品質、關鍵字優化都差不多時，Core Web Vitals 更好的那個會獲得優先。這在競爭激烈的關鍵字區段特別明顯。
更實際的影響其實在另一個地方：Google 的 Search Console 會把 Core Web Vitals 不佳的頁面標為「不良」，這類頁面可能影響整體網站的抓取預算與排名評估。如果你整個網站有大量頁面分數很差，整體域名的評分也會被拖累。
這跟 GEO（生成式引擎優化）的邏輯也有關聯——AI 引擎在評估是否引用一個來源時，頁面的可信度與使用者體驗訊號都是考量因素之一。分數差的頁面，AI 引擎也不太願意引用。
常見誤解：很多人在這裡想歪了
誤解一：Core Web Vitals 只要過一次就好 Google 測量的是「真實使用者資料」（Field Data），不是你跑一次 PageSpeed Insights 的實驗室數據。流量組成、裝置、網路環境都會影響分數，要持續監控。
誤解二：桌機版過了就沒事 Google 以行動版為主要索引（Mobile-First Indexing），行動版的 Core Web Vitals 才是主要評分依據。你的桌機版很快，但手機版還在 3G 環境下跑 4 秒，那分數還是差。
誤解三：LCP 只跟圖片有關
LCP 元素可以是文字區塊、背景圖、甚至是一段 <p> 標籤。不是只有圖片才要優化。
怎麼量、在哪裡看
幾個實際工具：
- Google Search Console：左側「體驗 > 核心網頁指標」，看真實使用者的聚合數據，是最重要的參考來源
- PageSpeed Insights（pagespeed.web.dev）：同時給你 Lab 數據和 Field 數據，還會列出具體優化建議
- Chrome DevTools > Lighthouse：本機測試用，適合開發階段
- CrUX Dashboard（Chrome UX Report）：可以追蹤你的網站在 Chrome 使用者中的歷史趨勢
值得一提的是，如果你的網站流量不夠（通常要達到一定門檻，Google 才有足夠的真實資料），Search Console 可能顯示「資料不足」，這時候就只能靠 Lab 數據估計。
結語：體驗分數是基本功，不是加分題
Core Web Vitals 不是你把 SEO 做完之後再來處理的東西，它應該在網站建置階段就納入考量。一個 LCP 3.8 秒、CLS 0.3 的網站，就算內容再好、結構化資料標記再完整，也很難跟體驗優秀的競爭對手拉開差距。
如果你的網站還沒做過 Schema.org 結構化資料標記，或者想進一步讓內容被 AI 引擎引用，建議先把 Core Web Vitals 調到綠燈，再去做那些進階優化——因為 AI 引擎和搜尋引擎都會用頁面品質訊號來篩選來源，Perplexity 等 AI 工具決定引用哪個網站時也把這些訊號納入考量。
下一步：去 Search Console 看你的核心網頁指標報告，找出「不良」頁面，優先處理 LCP 和 CLS——這兩個通常最好下手。
常見問題
Core Web Vitals 分數不好，網站一定排名會掉嗎？
不一定。Google 官方說 Core Web Vitals 是排名因素之一，但內容品質、E-E-A-T 等訊號權重更高。分數差的影響通常在競爭激烈的關鍵字上較明顯，或當多個頁面出現「不良」時拖累整體網站評估。
INP 和舊的 FID 有什麼不同？
FID 只量測第一次互動的延遲，INP 則追蹤整個瀏覽過程中所有點擊、輸入事件的回應速度，並取較差的那段數據計算。INP 從 2024 年 3 月正式取代 FID，對 JavaScript 執行較重的網站影響更大。
PageSpeed Insights 的 Lab 數據和 Field 數據哪個才算數？
Google 排名使用的是 Field Data（真實使用者資料），也就是 CrUX 資料庫收集的數據。Lab Data 是模擬測試，適合找問題用，但不代表實際使用者體驗。Search Console 顯示的核心網頁指標才是 Google 評分的依據。
CLS 高通常是什麼原因造成的，要怎麼快速改善？
最常見的原因是圖片或影片沒有設定固定寬高（width/height 屬性），以及動態插入的廣告或橫幅沒有預留空間。最快的改法是給所有圖片加上明確的寬高屬性，並為會動態出現的元件設定佔位 skeleton。
網站流量很少，Search Console 顯示資料不足，該怎麼辦？
流量不足時，Google 沒有足夠的真實使用者資料可以呈現。這時候以 PageSpeed Insights 的 Lab 數據和 Lighthouse 為參考，把三項指標的分數目標設在「好」的門檻內，等流量增加後 Field Data 就會逐漸出現。
分享這篇
