Core Web Vitals 是什麼？LCP、INP、CLS 三大指標與優化入門

Core Web Vitals 是 Google 用來衡量「真實使用者打開網頁時體驗好不好」的三個指標：LCP（主要內容多快出現）、INP（點下去多快有反應）、CLS（畫面會不會亂跳）。三項的及格線分別是 LCP 2.5 秒、INP 200 毫秒、CLS 0.1，而且是以第 75 百分位的實際造訪數據來判定，不是單次測速的結果。

聽過「網站速度會影響排名」的人，常常卡在下一步：到底要看哪個數字？PageSpeed Insights 分數 90 分，為什麼 Search Console 還是說「不良」？這篇文章把三個指標的定義、及格門檻、怎麼查、怎麼改依序拆開，最後整理成一套可以照著做的優先順序。

先講結論：Core Web Vitals 是排名系統會參考的訊號之一，但不是內容品質的替代品。值得花力氣改，但不要期待分數變綠就會衝上第一頁。

Core Web Vitals 三大指標一次看懂

三個指標各管一件事，門檻與評級如下。這張表就是 Search Console 報表使用的判定標準：

表格中的區間依據 Search Console 說明文件。有兩個細節常被忽略：

• 看的是第 75 百分位：意思是要有至少 75% 的造訪達到「良好」，這一項才算過。少數使用者網路很慢不會直接拉垮整體，但如果有四分之一以上的人體驗很差，就會被判定不及格。
• 手機和桌機分開算：同一個網址，桌機及格、手機不及格是很常見的狀況。

LCP：主要內容多快出現

LCP 記錄的是畫面可視範圍內「最大的那塊內容」完成繪製的時間點，從使用者開始載入頁面起算。被納入計算的元素類型有限：圖片、影片、CSS 背景圖與包含文字的區塊元素等。

實務上，部落格文章的 LCP 通常是首圖或標題文字區塊；電商商品頁多半是主商品圖；形象官網則常是首屏的大型 Banner。知道自己網站的 LCP 元素是哪一個，是優化的第一步。

INP：點下去多快有反應

INP 觀察使用者整段造訪期間的所有互動，取「最慢的那一次」作為代表值。只有 點擊、觸控、按鍵 三種互動會被計入，滑動、捲動、縮放不算。互動次數很多的頁面會排除極端值：每 50 次互動忽略 1 次最高值。

一次互動的延遲可以拆成三段：

1. 輸入延遲（Input Delay）：使用者點了，但瀏覽器主執行緒正在忙別的事，事件處理程式還沒開始跑。
2. 處理時間（Processing Duration）：事件處理程式本身的執行時間。
3. 呈現延遲（Presentation Delay）：程式跑完到下一個畫面真正畫出來的時間。

INP 在 2024 年 3 月 12 日 正式取代 FID（First Input Delay）成為 Core Web Vitals。FID 只量「第一次互動」的輸入延遲，INP 則看整段造訪的所有互動、而且三段延遲都算，所以門檻實際上變嚴格了。網路上 2024 年以前的文章如果還在教 FID，可以直接略過那一段。

CLS：畫面會不會亂跳

CLS 量的是「非預期的版面位移」。最典型的例子：正要點一個連結，上方突然插進一則廣告，整段內容往下推，結果點錯地方。

計算方式是每次位移的分數為 影響比例 × 距離比例，再把短時間內連續發生的位移（間隔小於 1 秒、總長不超過 5 秒）加總成一個「工作階段視窗」，取整個頁面生命週期中最大的那個視窗作為 CLS。使用者自己點擊、輸入後 500 毫秒內發生的位移屬於預期內，不會被計入。

Core Web Vitals 對 SEO 排名影響有多大？

這是最多人問、也最容易被誇大的問題。Google 官方文件的說法可以整理成三點：

• 會參考，但不是單一訊號：官方說明排名系統會看多種與頁面體驗相關的訊號，「There is no single signal」。
• 相關性優先：同一份文件寫明 Google 搜尋會優先呈現最相關的內容，即使該頁面的體驗不理想。
• 報表全綠不保證排第一：Search Console 或第三方工具顯示良好，不代表頁面一定會排到搜尋結果頂端。

Google 另一份 Core Web Vitals 說明頁 的措辭是：達到良好的 Core Web Vitals「aligns with what our core ranking systems seek to reward」——也就是方向一致，但沒有承諾具體權重。

比較務實的理解方式：當兩個頁面的內容相關性、品質相近時，體驗較好的那個比較有優勢；但一篇沒有回答到搜尋意圖的文章，就算 LCP 1 秒也救不回來。另一方面，Core Web Vitals 反映的是真實使用者的感受，載入慢、按了沒反應、畫面亂跳，本身就會讓訪客流失，這部分跟排名無關也值得改。

如果網站連基本收錄都還有問題，先處理 網站沒被 Google 收錄 的狀況會比優化速度更急迫；技術面的整體架構可以參考 SEO 實戰篇【上】：技術架構篇。

現況：多少網站三項都及格？

HTTP Archive 每年發布的 Web Almanac 會用 CrUX 數據統計整體網路的表現。根據 Web Almanac 2025 效能章節，手機版只有 48% 的網站三項 Core Web Vitals 全部及格，桌機版為 56%。

從各項指標拆開來看，有幾個值得注意的地方：

• 手機 LCP 是最大的瓶頸：只有 62% 的網站及格，是手機三項中最低的。手機網速與處理器效能都比桌機弱，大圖、慢伺服器的問題會被放大。
• INP 在桌機幾乎沒問題，手機才是重點：桌機 97% 及格，手機降到 77%，差距主要來自手機處理器跑 JavaScript 比較慢。
• CLS 反而是桌機比較差：桌機 72%、手機 81%。所以不要假設「手機過了，桌機一定沒問題」，兩個版本都要各自檢查。

同一份報告也列出幾個很基本、卻仍普遍存在的問題：約 16–17% 的頁面對 LCP 圖片使用了延遲載入（lazy loading），62% 的手機頁面至少有一張圖片沒有指定尺寸，而在 LCP 是圖片的手機頁面中，只有 17.3% 使用 fetchpriority=”high”。這些都是改動成本很低的項目，後面的優化段落會再提到。

怎麼查自己網站的 Core Web Vitals？

查之前要先分清楚兩種數據，這是「PageSpeed 分數很高、Search Console 卻說不良」最常見的原因。

web.dev 的說明很直接：應該用實地數據決定優先順序，因為它才反映真實使用者的體驗。實驗室數據只用單一裝置、單一網路、單一地點測試，無法反映使用者實際的快取狀態、裝置差異與互動行為；例如實驗室測試無法預測使用者什麼時候、點哪裡，所以 INP 只能靠實地數據判斷，Lighthouse 只能用 Total Blocking Time（TBT）作為參考。

PageSpeed Insights：兩個區塊分開看

在 PageSpeed Insights 輸入網址後，畫面會分成兩塊：

1. 上半部：實際使用者的體驗：這是實地數據，涵蓋 過去 28 天 的真實造訪。這裡顯示「通過」或「未通過」Core Web Vitals 評估，才是 Google 看的結果。
2. 下半部：效能問題診斷：這是 Lighthouse 的實驗室數據，0–100 的效能分數就在這裡。90 分以上為良好，但這個分數本身不是 Core Web Vitals。

流量太少的頁面，上半部可能沒有網址層級的數據，工具會改顯示整個網域（origin）的數據；如果整個網域的數據也不夠，就只剩實驗室數據可看。新站或流量小的網站經常遇到這種情況，這時只能先用實驗室數據當方向參考。

Search Console：看全站哪些網址出問題

PageSpeed Insights 一次只能查一個網址，Search Console 的 Core Web Vitals 報表（中文介面稱為「核心網頁指標」）則能看全站。幾個判讀重點：

• 網址會被分組：體驗相近的網址（例如同一個版型的文章頁）會被歸為一組，修好版型就能一次解決整組。
• 以最差的一項為準：一組網址只要有一項指標不良，整組就顯示「不良」。
• 需要足夠數據才會出現：流量太少的網址不會被列出。
• 驗證要等 28 天：修好後按「驗證修正」，Search Console 會開始一段 28 天的監控期，確認修正有效。

還沒設定 Search Console 的話，可以先參考 SEO 實戰篇【零】：先裝好你的「儀表板」。

LCP 優化：先找出時間花在哪一段

LCP 不是單一問題，web.dev 把它拆成四個子階段，並給出各段大致的理想佔比。先用 Chrome DevTools 的 Performance 面板找出時間卡在哪一段，再對症下藥：

佔比出自 Optimize Largest Contentful Paint。對應每一段的常見做法：

• TTFB 太長：減少不必要的轉址、使用 CDN、做好伺服器端快取。共享主機或沒有快取的 WordPress 網站常卡在這裡。
• 資源載入延遲太長：讓 LCP 圖片直接寫在 HTML 裡（而不是靠 JavaScript 動態插入），並加上 fetchpriority=”high”；不要對首屏的 LCP 圖片使用 loading=”lazy”，這是最常見也最容易修的錯誤。
• 資源載入時間太長：壓縮圖片、改用 WebP 或 AVIF 等較新的格式、依螢幕尺寸提供適當大小的圖片。
• 元素渲染延遲太長：減少會阻擋渲染的 CSS 與 JavaScript，非必要的腳本延後載入。

INP 優化：讓主執行緒有空回應使用者

INP 不好，幾乎都是同一個根源：瀏覽器的主執行緒被 JavaScript 佔住，使用者點了也排不到隊。對應三段延遲，web.dev 的優化建議 可以整理成：

• 降低輸入延遲：減少頁面載入期間的長任務。第三方腳本（廣告、追蹤碼、聊天外掛、熱圖工具）是常見來源，先盤點哪些真的需要。
• 縮短處理時間：事件處理程式只做「讓畫面先有反應」的必要工作，其餘的（例如送出分析事件）切成獨立任務，用 setTimeout 等方式讓出主執行緒，晚一點再跑。
• 縮短呈現延遲：控制 DOM 大小，DOM 節點越多，每次重新繪製的成本越高；畫面外的區塊可以用 CSS content-visibility 延後渲染。
• 避免版面抖動（layout thrashing）：不要在同一個任務裡先改樣式、馬上又讀取元素尺寸，這會逼瀏覽器同步重算版面。

對不寫程式的網站主來說，最實際的槓桿通常是「拿掉用不到的外掛和第三方腳本」。官方文件也提醒 INP 優化是反覆的過程，修好一個慢互動後，常會發現下一個。

CLS 優化：先幫每個元素保留位置

CLS 的修法相對單純，核心原則是「內容還沒載入前，就先把位置留好」。web.dev 列出的主要做法：

1. 圖片與影片加上 width、height：或用 CSS aspect-ratio，讓瀏覽器在圖片下載前就知道要留多大空間。前面提到 62% 的手機頁面至少有一張圖沒指定尺寸，這是很常見的 CLS 來源。
2. 廣告與嵌入內容預留空間：用 min-height 先撐出廣告欄位的高度；動態插入的內容盡量放在畫面較下方，避免把使用者正在看的內容往下推。
3. 動畫用 transform：不要用改變 top、left 的方式做動畫，transform 不會觸發版面重算。
4. 處理網頁字型：字型載入完成後替換備用字型，可能造成文字區塊尺寸改變。可以預先載入關鍵字型、設定 font-display、選擇尺寸相近的備用字型。中文字型檔案通常較大，這點特別值得注意。
5. 讓頁面支援 bfcache：使用者按上一頁時直接從記憶體還原頁面，不會重新載入，也就不會再次位移。

從哪裡開始改？一套排查流程

資源有限的話，可以依照這個順序處理，避免一開始就陷進細節：

1. 先看 Search Console 的 Core Web Vitals 報表：確認是手機還是桌機、哪個指標、哪一組網址不良。多數網站應該先看手機。
2. 挑影響最大的網址組：通常是流量最高的版型（文章頁、商品頁），修一個版型等於修一整組。
3. 用 PageSpeed Insights 查該組的代表網址：上半部確認實地數據哪一項沒過，下半部的診斷建議當作線索。
4. 先做低成本、高命中率的修正：LCP 圖片拿掉 lazy loading、加上 fetchpriority=”high”；所有圖片補上尺寸；移除用不到的外掛與第三方腳本。
5. 用實驗室數據快速驗證：改完先用 Lighthouse 或 DevTools 確認方向正確，不用等 28 天才知道有沒有改到。
6. 在 Search Console 按「驗證修正」：等待 28 天的監控期結束，以實地數據為最終結果。

如果網站架構本身就有問題（例如主機太慢、佈景主題過度臃腫），第 4 步的小修正效果會有限，這時才需要考慮換主機、換主題或重構前端。

Core Web Vitals 常見問題

PageSpeed Insights 分數 90 分以上，為什麼 Core Web Vitals 還是沒過？

那個 0–100 的分數來自 Lighthouse 的實驗室數據，只是在固定環境模擬一次載入；Core Web Vitals 的判定則看真實使用者過去 28 天的實地數據。使用者的手機較舊、網路較慢，或頁面上的互動與廣告在實驗室測試中沒有被觸發，都可能造成兩者落差。以 PageSpeed Insights 上半部的實地數據為準。

網站流量很小，查不到 Core Web Vitals 數據怎麼辦？

CrUX 需要累積足夠的造訪數據才會顯示，流量太小的網址會改顯示整個網域的數據，甚至完全沒有。這種情況下只能先參考實驗室數據，按照本文的優化清單處理常見問題。對新站來說，內容與收錄通常比 Core Web Vitals 更優先。

FID 還需要看嗎？

不需要。FID 已在 2024 年 3 月由 INP 取代，現在的 Core Web Vitals 只有 LCP、INP、CLS 三項。

改完之後多久會反映在 Search Console？

實地數據是過去 28 天的累積，所以改善需要一段時間才會完整反映。在 Search Console 按下驗證修正後，監控期為 28 天。

Core Web Vitals 及格後，排名一定會上升嗎？

不一定。Google 官方明確表示，報表結果良好不保證排在搜尋結果頂端，相關性仍是最優先的考量。Core Web Vitals 比較像是門檻與加分項，而不是排名的主要驅動力。

參考資料

1. Web Vitals（web.dev）
2. Core Web Vitals report（Search Console Help）
3. Largest Contentful Paint (LCP)（web.dev）
4. Interaction to Next Paint (INP)（web.dev）
5. Interaction to Next Paint becomes a Core Web Vital on March 12（web.dev）
6. Cumulative Layout Shift (CLS)（web.dev）
7. Understanding page experience in Google Search results（Google Search Central）
8. Understanding Core Web Vitals and Google search results（Google Search Central）
9. Performance | 2025 | The Web Almanac by HTTP Archive（HTTP Archive）
10. Why lab and field data can be different (and what to do about it)（web.dev）
11. About PageSpeed Insights（Google for Developers）
12. Optimize Largest Contentful Paint（web.dev）
13. Optimize Interaction to Next Paint（web.dev）
14. Optimize Cumulative Layout Shift（web.dev）