Core Web Vitals 是什麼？LCP、INP、CLS 三大指標門檻與改善方法

打開 PageSpeed Insights，一堆紅色、橘色的分數和英文縮寫：LCP、INP、CLS……很多老闆看完只有一個疑問：「這到底影不影響我的生意？」Core Web Vitals（核心網頁指標）是 Google 用來衡量真實使用者體驗的三項指標，分別對應「載入快不快」「點了有沒有反應」「畫面會不會亂跳」。

這篇文章會用白話說明三項指標的意義與官方門檻，教你怎麼檢測，並整理每個指標最常見的問題與改善方向。我們也會誠實說明：Core Web Vitals 對排名的影響有多大，以及什麼時候值得投資優化。SEO 的整體觀念可以參考 2026 SEO 完整指南。

Core Web Vitals 是什麼？三項指標一次看

依 web.dev 官方說明，目前的 Core Web Vitals 由三項指標組成：

指標	衡量什麼	良好	需要改善	不佳
LCP（最大內容繪製）	載入速度：主要內容多快出現	≤ 2.5 秒	2.5～4 秒	> 4 秒
INP（與下一次繪製的互動）	互動反應：點擊後多快看到回饋	≤ 200 毫秒	200～500 毫秒	> 500 毫秒
CLS（累計版面配置位移）	視覺穩定：畫面會不會突然移動	≤ 0.1	0.1～0.25	> 0.25

幾個評估規則要特別注意：

Google 建議以第 75 百分位數評估，也就是至少 75% 的造訪都要達到「良好」
行動裝置與桌機分開計算，台灣多數網站的行動流量佔比高，行動版更要優先處理
三項指標都達到良好，才算通過 Core Web Vitals 評估

另外，INP 在 2024 年 3 月 12 日正式取代 FID（首次輸入延遲）成為核心指標。FID 只衡量「第一次」互動的延遲，INP 則觀察整個造訪過程中的所有點擊、觸控與按鍵互動，更能反映真實體驗。網路上還在教 FID 的文章，已經過時了。

Core Web Vitals 會影響 SEO 排名嗎？

Google〈網頁體驗〉文件的說法很值得完整理解：

Google 的排名系統確實會使用 Core Web Vitals，並建議網站達到良好分數
但沒有單一的「網頁體驗訊號」，排名系統會綜合許多訊號
分數好不代表一定排第一，內容的關聯性仍然是最重要的
當很多網頁的內容都同樣有幫助時，良好的網頁體驗才更可能成為勝出的關鍵
只為了 SEO 而追求滿分，未必是最好的時間投資

換句話說，Core Web Vitals 比較像是「及格門檻」與「同分時的加分」，而不是排名的萬靈丹。但別忘了它真正衡量的是使用者體驗：頁面載入慢、按鈕點了沒反應、要按「加入購物車」時畫面突然跳動，這些都會直接影響詢價與成交，跟排名無關也值得改善。

怎麼檢測 Core Web Vitals？

檢測工具分成兩類，差別很重要：

實際使用者資料（Field Data）

來自真實 Chrome 使用者的造訪紀錄，這才是 Google 評估時參考的資料：

PageSpeed Insights：輸入網址，上半部「探索實際使用者的體驗」就是實際資料
Search Console 的 Core Web Vitals 報表：依網址群組列出全站哪些頁面不佳
Chrome 使用者體驗報告（CrUX）：Google 公開的實際使用者資料集

如果網站流量太少，可能沒有足夠的實際資料可以顯示。

實驗室資料（Lab Data）

在模擬環境中測試，適合用來找問題、驗證修改：

Lighthouse（PageSpeed Insights 下半部也是用它）：一般的載入測試可以量測 LCP 與 CLS，但無法量測 INP，因為模擬測試中沒有真人互動，所以改用「總封鎖時間」（TBT）作為參考
Chrome 開發人員工具：效能面板可以觀察三項指標與長工作

常見的誤會是只看 Lighthouse 的總分。總分漂亮不代表實際使用者體驗良好，反之亦然。判斷是否通過，以實際使用者資料為準；找原因、測修改，用實驗室資料。

LCP：主要內容多快出現

LCP 衡量的是畫面中最大的圖片或文字區塊完成繪製的時間。在多數企業網站上，它通常是首頁的大橫幅圖、商品主圖或文章開頭的標題段落。

web.dev 把 LCP 拆成四個部分，可以幫助找出慢在哪裡：

伺服器回應時間（TTFB）：瀏覽器收到 HTML 第一個位元組的時間
資源載入延遲：從收到 HTML 到開始下載 LCP 圖片之間的空檔
資源載入時間：下載 LCP 圖片本身花的時間
元素算繪延遲：圖片下載完，到真正顯示在畫面上的時間

LCP 常見問題與改善

首屏大圖被設定延遲載入：web.dev 明確指出，LCP 圖片絕對不要 lazy load。很多佈景主題或外掛會對所有圖片套用延遲載入，首屏大圖要排除
圖片太大：手機版還在載入 3000 像素寬的原圖。改用 WebP、AVIF 等新格式，依裝置提供合適尺寸
瀏覽器太晚發現圖片：如果首屏大圖寫在 CSS 背景或由 JavaScript 動態插入，瀏覽器要等很久才知道要下載。讓圖片直接出現在 HTML 中，並對它加上 fetchpriority="high"
主機回應慢：便宜的共享主機、沒有快取的 WordPress、過多轉址，都會拉長 TTFB。使用伺服器快取與 CDN 通常有明顯改善
阻擋算繪的 CSS 與 JavaScript：<head> 裡同步載入的大量腳本，會讓圖片下載好了卻遲遲無法顯示

圖片格式與快取的實作細節，可以延伸閱讀網站速度與圖片優化。

INP：點了之後多快有反應

INP 衡量使用者點擊、觸控、按鍵之後，到畫面出現下一個視覺回饋所花的時間。滑鼠移過與捲動不計入。一次互動的延遲可以拆成三段：

輸入延遲：使用者點了，但主執行緒正在忙別的事，事件處理要排隊等待
處理時間：事件處理程式本身執行的時間
呈現延遲：處理完成後，瀏覽器重新排版、繪製出下一個畫面的時間

INP 常見問題與改善

在台灣的企業網站與電商上，INP 不佳最常見的原因是第三方腳本太多：多套追蹤碼、即時客服、彈出視窗、熱點分析工具同時載入，讓主執行緒一直處於忙碌狀態。改善方向包括：

盤點並精簡第三方腳本，不再使用的追蹤碼與外掛直接移除
把長工作拆小：web.dev 建議讓事件處理只先做「更新畫面所需的最少工作」，其餘工作延後執行，讓瀏覽器有機會先畫出回饋
避免版面配置反覆計算：在 JavaScript 中修改樣式後立刻讀取尺寸，會強迫瀏覽器同步重新排版
控制 DOM 大小：頁面元素過多，每次更新畫面的成本就越高；畫面外的大區塊可考慮使用 content-visibility
給使用者即時回饋：例如按下「送出」後立即顯示載入狀態，再處理後續工作

INP 的改善通常需要前端工程能力，如果網站由套版或大量外掛組成，可能要從架構面重新評估。

CLS：畫面會不會突然跳動

你一定遇過：正要點某個連結，上方突然插入一塊廣告，結果點到別的東西。這就是版面配置位移，CLS 衡量的就是這種「非預期的移動」程度。使用者點擊、觸控或按鍵後 500 毫秒內發生的位移，屬於預期中的變化，不會計入。

CLS 常見原因與改善

依 web.dev 整理的常見原因：

圖片、影片沒有設定尺寸：瀏覽器不知道要預留多少空間，圖片載入後把下方內容往下推。解法是替圖片加上 width、height 屬性，或用 CSS 的 aspect-ratio 預留空間
網頁字型替換造成跳動：中文網頁字型檔案大，載入前後字寬、行高不同，整段文字重新排列。可以挑選尺寸接近的備用字型，或只對標題使用網頁字型
廣告、嵌入內容、第三方小工具自行改變大小：替這些區塊預留固定高度
動態插入內容：例如頂部的優惠公告列、Cookie 同意橫幅晚一步才出現，把整頁往下推。改為覆蓋在畫面上，或一開始就預留位置
動畫使用了會改變版面的屬性：改用 CSS transform 製作動畫

優化的優先順序建議

資源有限時，建議依這個順序處理：

打開 Search Console 的 Core Web Vitals 報表，先處理行動版中被標示為「不佳」的網址群組
優先處理流量最大、最接近轉換的頁面：首頁、熱門服務頁、商品頁、結帳流程
先做低成本、高效果的修正：圖片壓縮與尺寸、移除首屏大圖的延遲載入、刪除不用的外掛與追蹤碼、替圖片設定尺寸
涉及主機、框架或前端架構的問題，再評估是否需要較大的工程投入；若同時有爬取或索引問題，先參考技術 SEO：爬取與索引一併檢查，行動版版面則可搭配行動優先與 RWD 響應式設計調整
修正後持續觀察：實際使用者資料以過去一段時間的造訪累計，改善需要一段時間才會反映在報表中

常見問題

PageSpeed Insights 分數一定要 90 分以上嗎？

不需要。Lighthouse 總分是實驗室模擬結果，不是 Google 排名使用的依據。真正要看的是實際使用者資料中，LCP、INP、CLS 三項是否達到「良好」門檻。Google 也提醒，只為了 SEO 追求滿分未必值得。

為什麼 Lighthouse 很好，Search Console 卻顯示不佳？

兩者資料來源不同。Lighthouse 是在固定條件下的單次模擬，Search Console 反映的是真實使用者在各種手機與網路環境下的實際體驗，而且是一段期間的累計資料。實際使用者的裝置可能較舊、網路較慢，結果自然不同。

網站流量很少，看不到 Core Web Vitals 資料怎麼辦？

實際使用者資料需要足夠的造訪量才會顯示。這時可以先用 Lighthouse 與 Chrome 開發人員工具做實驗室測試，找出明顯問題；也可以在網站裝設 web-vitals JavaScript 程式庫，自行蒐集真實使用者的指標。

換主機能解決所有速度問題嗎？

不一定。主機主要影響伺服器回應時間，對 LCP 有幫助，但 INP 多半和網頁上的 JavaScript 有關，CLS 則和版面設計有關。換主機前，建議先用 LCP 的四個組成部分分析，確認瓶頸真的在伺服器端。

結語：速度是體驗，也是信任

Core Web Vitals 不是為了討好 Google 而存在的分數，而是把「好不好用」變成可以量化的指標。快速載入、即時回應、穩定不亂跳的網站，讓顧客更願意停留、詢價與下單，排名的加分只是附帶的好處。

如果你的網站有大量外掛、套版難以優化，或需要從架構面改善效能，網軍行銷的客製化網站開發可以協助評估與重建，讓速度和功能兼顧。

參考資料

web.dev Blog，Interaction to Next Paint becomes a Core Web Vital on March 12：https://web.dev/blog/inp-cwv-march-12
web.dev，Largest Contentful Paint (LCP)：https://web.dev/articles/lcp
web.dev，Optimize Largest Contentful Paint：https://web.dev/articles/optimize-lcp
web.dev，Interaction to Next Paint (INP)：https://web.dev/articles/inp
web.dev，Cumulative Layout Shift (CLS)：https://web.dev/articles/cls
Google Search Central，Understanding page experience in Google Search results：https://developers.google.com/search/docs/appearance/page-experience

Core Web Vitals 是什麼？LCP、INP、CLS 三大指標門檻與改善方法

Core Web Vitals 是什麼？三項指標一次看

Core Web Vitals 會影響 SEO 排名嗎？