Albert's SEO Note
輸入關鍵字開始搜尋

Core Web Vitals 完整指南，INP 取代 FID 後該怎麼優化

3 項 Core Web Vitals 優化策略：2024 年 INP 正式取代 FID，改為量測全工作階段的最差互動延遲。網站須確保 P75 真實使用者數據達標：LCP 低於 2.5 秒、INP 低於 200 毫秒、CLS 不超過 0.1。透過壓縮 TTFB、切分 JS 長任務與預留圖片尺寸等技術實作，能有效提升網頁效能與 SEO 排名。

Albert · · 21 min read
Core Web Vitals 完整指南，INP 取代 FID 後該怎麼優化

本文重點

  • INP 正式取代 FID，改測全工作階段最差互動延遲，網站的 P75 真實數據必須壓在 200 毫秒內。
  • LCP 須小於 2.5 秒，首要將 TTFB 壓進 600 毫秒內，並對首屏元素啟用預載與 CDN 快取。
  • INP 延遲多因主執行緒阻塞，必須將超過 50ms 的 JS 長任務切短，並延遲載入非必要第三方腳本。
  • CLS 須低於 0.1，防止版面位移的根本作法是為圖片與廣告預留固定尺寸，避免字體切換造成重排。

網站做了再多內容優化，只要打開速度太慢、按鈕點下去卡住、版面亂跳，使用者三秒內就會離開。Core Web Vitals（核心網頁體驗指標）正是 Google 用來量化這三件事的標準，也是 2021 年後正式列入排名因素的技術 SEO 指標。2024 年 3 月起 INP 正式取代 FID，這篇文章會帶你補上完整脈絡：三項指標各自的判讀標準、怎麼量測、實作上最有效的優化動作。

一、Core Web Vitals 是什麼

Core Web Vitals 是 Google 在 2020 年提出、用來量化「網頁載入體驗」的三項核心指標，由 LCP、INP、CLS 組成，自 2021 年 6 月起正式納入 Google 搜尋排名因素之一。

它隸屬於 Google 更大的「Page Experience」訊號家族，但 Core Web Vitals 是其中最具體、可量測的部分。簡單來說：LCP 量「網頁主要內容多快出現」、INP 量「使用者互動的回應快不快」、CLS 量「畫面有沒有亂跳」。三個指標都拿到「良好」級距，等於跟 Google 證明你的網站不是慢、不卡、不亂跳的好體驗，特別在行動裝置搜尋上影響更明顯。

二、INP 為何在 2024 取代 FID

2024 年 3 月 12 日起，INP（Interaction to Next Paint）正式取代 FID（First Input Delay）成為 Core Web Vitals 的互動指標。

舊的 FID 只量測「使用者第一次點擊到瀏覽器開始處理」之間的延遲，問題在於它只看第一次互動、且只看開始時間，完全忽略後續所有互動以及實際處理完的耗時。INP 則改為量測「整個 session 內所有互動的延遲，取最差的那筆」，並且包含完整流程：點擊 → 瀏覽器處理 → 主執行緒完成 → 下一次畫面更新。對使用者實際感受到的「卡頓」反映得更準確，這也是 Google 換標準的核心原因。

指標良好待改進不良
LCP≤ 2.5 秒2.5 – 4.0 秒> 4.0 秒
INP≤ 200 毫秒200 – 500 毫秒> 500 毫秒
CLS≤ 0.10.1 – 0.25> 0.25

要被 Google 認定為「通過 Core Web Vitals」，三項指標都要達到「良好」級距，且取的是第 75 百分位（P75）的真實使用者數據——意思是你 75% 的使用者體驗都要在標準內。

三、LCP（Largest Contentful Paint）優化

LCP 量測的是「網頁主要內容元素出現在畫面中的時間」，通常是首屏最大的圖片、影片或文字區塊。

LCP 慢的常見原因有四類：伺服器回應慢（TTFB 過長）、render-blocking 的 CSS / JS、LCP 元素本身的資源太大或載入太晚、客戶端渲染導致延遲。對應的優化動作：

  • 啟用 CDN 與快取：讓使用者從最近的節點抓資料，TTFB 通常能砍半。Cloudflare、Fastly、Vercel Edge 都是常見選擇。
  • 圖片優化：LCP 元素若是圖片，務必使用 WebP 或 AVIF 格式、加上 width / height 屬性、第一屏的圖片用 fetchpriority="high" 提早載入，下方的圖片才用 loading="lazy"。
  • 預載 LCP 資源：在 <head> 加 <link rel="preload" as="image" href="...">，告訴瀏覽器這張圖很重要、提前抓。
  • 減少 render-blocking JS / CSS：把非關鍵 CSS 改用 media 屬性延遲載入、把非必要 JS 加 defer 或 async。
  • 避開客戶端渲染的盲點：如果用 React / Vue 做 SPA，LCP 元素一定要走 SSR 或 SSG，不要等 JS 跑完才渲染。

TTFB 與 LCP 的因果關係

TTFB（Time to First Byte）是「使用者送出請求後，瀏覽器收到第一個位元組」的時間。TTFB 高的網站，LCP 幾乎不可能達標——因為 LCP 包含了 TTFB 的全部時間。判斷 TTFB 問題從哪裡來最直接的方式：用 Chrome DevTools 的 Network 面板看任一請求，「Waiting for server response」段就是 TTFB。如果這段超過 600ms，通常代表伺服器在計算頁面、查資料庫或跑同步阻塞的程式碼。先把 TTFB 壓進 600ms 以下，後面所有 LCP 優化動作才會見效。

四、INP（Interaction to Next Paint）優化

INP 量測的是「使用者每次互動到畫面完成更新」之間的延遲，包含點擊、按鍵、觸控但不含捲動。

INP 通常壞在「主執行緒被長任務卡住」，最典型的元兇是大型 JS bundle、第三方追蹤程式、複雜的事件處理器。優化的核心思路是把長任務切短、把不必要的 JS 移走：

（一）拆分長任務（Long Tasks）

任何超過 50ms 的 JS 任務都會讓主執行緒卡住、互動延遲飆高。把長函式拆成多個小函式，並用 scheduler.yield()（新 API）或 setTimeout(fn, 0) 主動讓出執行權，給瀏覽器空檔處理使用者輸入。

（二）延後或移除第三方腳本

GA、GTM、客服小工具、A/B 測試工具是 INP 的常見地雷。把非必要的第三方腳本改用 async 載入，或改成「使用者真的需要時才載入」（例如客服 widget 可以等使用者捲到頁尾再載）。

（三）善用 React 的 useTransition / useDeferredValue

如果用 React 18 以上版本，把非緊急更新（搜尋過濾、即時排序）包進 useTransition，讓 React 把更新標記為低優先，避免阻塞使用者輸入回應。

（四）避免在事件處理器裡做重 DOM 操作

點擊一個按鈕後同步觸發大量 DOM 操作（例如重排整個表格），是經典 INP 殺手。把這類重操作丟到 requestIdleCallback 或下一個 microtask，讓畫面先回應使用者再做後續工作。

五、CLS（Cumulative Layout Shift）優化

CLS 量測的是「視覺穩定性」，計算頁面載入過程中、使用者沒有預期的版面位移總量。CLS 過高最大的後果是：使用者本來要點 A，畫面突然跳一下變成點到 B（最常見的就是誤點到廣告）。

CLS 壞掉的根本原因，幾乎都是沒給瀏覽器足夠資訊預留空間。常見地雷與對策：

  • 圖片沒有預留尺寸：所有 <img> 與 <video> 都要加 width 和 height 屬性，讓瀏覽器在資源還沒載完時就預留空間。
  • 動態插入廣告或 banner：頂部插入的廣告會把下面整片內容往下推。對策：用固定高度的容器把廣告位包起來，即使廣告還沒回來，版面也不會跳。
  • 網頁字體切換造成重排（FOIT / FOUT）：使用 font-display: optional 或預先載入字體，避免字體切換時整段文字的高度突然變動。
  • Cookie consent 橫幅：用 position: fixed 讓它浮在內容上方，不要直接 push 內容下去。

CLS 與 SEO 的關聯不只是「Google 喜不喜歡」，更直接影響使用者體驗——版面亂跳的網站，讀者很快就點返回鈕走人，連帶拉低 dwell time 與內容信號（what-is-eeat）。

六、怎麼量測 Core Web Vitals

量測分為「實驗室數據（Lab Data）」與「真實使用者數據（Field Data）」兩種，兩者要搭配看。

（一）PageSpeed Insights（最常用）

直接貼上網址，會同時給你 Lab 與 Field 兩種數據。Field 數據來自 CrUX（Chrome User Experience Report）資料庫，是 Google 拿來判定 SEO 排名因素的數據；Lab 數據則是 Lighthouse 即時跑的，受網路環境影響較大、僅供參考。

（二）Google Search Console 的 Core Web Vitals 報表

GSC 會把網站所有網址依 LCP / INP / CLS 分群並標記「良好 / 待改進 / 不良」，是看「整站健康度」最實用的入口（詳見 google-search-console-complete-guide）。

（三）Chrome DevTools Performance 與 Lighthouse

開發階段最常用：DevTools 的 Performance 分頁能精準看到 LCP 元素是哪個、長任務在哪一段；Lighthouse 則是綜合報告，會直接給優化建議清單。

（四）真實使用者監測 RUM

進階做法是部署 RUM 工具（如 web-vitals.js、SpeedCurve、New Relic），把每個真實使用者的 Core Web Vitals 上報到自己的後台。對流量大的網站來說，RUM 比 CrUX 更即時、能拆得更細（例如分國家、分裝置、分頁面類型）。最低成本的實作是直接引用官方 web-vitals.js 套件，把每筆指標送到 GA4 自訂事件，再用 Looker Studio 做儀表板，不到一個下午就能完成。

（五）Lab 與 Field 數據為何常常差很大

很多人第一次對比 PageSpeed Insights 上下兩段時都會嚇一跳：上面 Field 寫「不良」、下面 Lab 卻 95 分。原因有三個：Lab 是模擬「中階手機 + Slow 4G」的單次測試，Field 則是真實使用者所有裝置與網路的統計平均；Lab 沒有第三方腳本動態載入的負擔（廣告、追蹤等只在真實環境會跑）；Lab 也測不出真實使用者的互動行為。要看 SEO 真實影響，永遠以 Field 數據為準。

七、Core Web Vitals 不是萬靈丹

在開始大改網站前先想清楚：Core Web Vitals 對 SEO 是「加分項」，不是「決勝因素」。

Google 多次公開說明過：在內容相關性差不多的情況下，Core Web Vitals 才會成為差別關鍵；但內容深度與權威性差太多時，速度再快也救不回來。實際排名觀察也支持這個說法——許多 Core Web Vitals 完全紅燈的競品，靠著內容深度與外部連結照樣排在第 1 名。所以判斷自己該不該花時間優化的標準是：內容與外部連結是否已經跟首頁前 5 名相當？如果是，效能優化就是擠進首頁的決勝武器；如果還差很多，先把資源投資在內容與內部連結上，效能優化等內容站穩後再做。

八、行動裝置優化重點

Google 在 2023 年 10 月完成全站改採 Mobile-first Indexing，意味著爬蟲看的是行動版的 Core Web Vitals，桌機分數再高也救不了行動版的爛體驗。

行動裝置上最常見的瓶頸：CPU 比桌機慢 4–6 倍、4G 網路延遲高、螢幕小但圖片照樣傳大張。對應的關鍵動作：

  • 用 srcset 與 sizes 對行動裝置送對應尺寸的圖片，不要桌機行動版都吃同一張 2000px 的圖。
  • 避免在行動裝置上載大型 JS 套件，能 code-split 就拆。
  • 行動版的字體一定要 font-display: swap 或 optional，3G 環境下 FOIT 會直接讓 LCP 噴掉。
  • 行動版的 viewport meta 要設好（width=device-width, initial-scale=1），否則整個版面會被縮放搞亂、CLS 也會跟著爆。
  • 行動裝置上盡量避免大量浮動元素或彈出層（Modal），這類元素同時會推升 INP 與 CLS，是行動版分數最常見的雙重殺手。

九、優化順序的實戰建議

當三項指標同時掉到「不良」級距，從哪裡開始改最有效？依照影響範圍與修復成本排序，建議的優先順序是：CLS → LCP → INP。

CLS 通常是版面結構問題，集中修一次（補上 width / height、固定廣告容器、調整字體載入策略）就能整站受益，且修復成本最低。LCP 牽涉伺服器、CDN、圖片格式與 render-blocking 資源，影響範圍大但有明確 checklist，依序處理也能在 1–2 週內看到大幅改善。INP 通常是最棘手的：問題往往散在多支 JS 與第三方腳本中，需要逐個情境錄製 Performance trace、找出 long task 來源，預期會花上 4–8 週才會看到 P75 數字明顯下降。先動低 hanging fruit，再進入長尾優化，整體投報率最高。

十、常見實作錯誤

下面這些錯誤很常見，但因為「桌機跑分還行」就被忽略，最後在 GSC 真實使用者數據上踢到鐵板。

  • 只看 Lighthouse 跑分，不看 CrUX：Lighthouse 是模擬數據，跟真實使用者經驗常常差 20–30 分。要看 SEO 影響，永遠以 PageSpeed Insights 上方的 Field 數據為準。
  • 改完沒等 28 天就以為沒效：CrUX 是 28 天滾動平均，今天修好不代表明天分數就會跳，至少要等兩週才能合理判斷成效。
  • 過度追求滿分而忽略內容：Core Web Vitals 是排名「加分項」，不是核心。在內容深度與權威性還沒站穩前（what-is-eeat），把時間花在效能微調的 ROI 通常不高。
  • 只優化首頁，忽略內頁：CrUX 是「整站」的分組統計，內頁佔流量大宗時，內頁體驗才是真正影響 SEO 的關鍵。

十一、FAQ

（一）Q1: Core Web Vitals 對排名的權重到底有多大

Google 公開說明過：在內容相關性差不多的情況下，Core Web Vitals 才會成為「決勝因素」。換句話說，內容夠好但稍微慢一點，依然贏內容差但跑很快的網站。它是排名加分項，不是核心。但在競爭激烈的關鍵字、或邊緣排名（第 8–15 名爭奪）情境下，Core Web Vitals 達標常常就是擠進首頁的關鍵。

（二）Q2: 我的網站只有桌機分數高、行動分數差，會被扣分嗎

會。Google 全面採用 Mobile-first Indexing，等於只用行動版的 Core Web Vitals 評分，桌機跑滿分也救不回來。要看你網站對 SEO 真實的影響，永遠以 PageSpeed Insights 上方的「行動版」Field 數據為準。

（三）Q3: INP 太高該從哪裡開始改

第一步用 Chrome DevTools 的 Performance 分頁錄下使用者實際操作（例如點擊主要 CTA），找出最長的那一筆 long task 是哪個檔案、哪一段函式造成的。八成以上的 INP 問題會落在第三方腳本（GTM、客服 widget、廣告 SDK）或 React 重渲染。先從第三方腳本改 async 或延後載入下手，再回頭看主應用程式的 long task 拆分。

#技術 SEO #網站效能
Share
Facebook ↗ LinkedIn ↗
Written by

張家偉 Albert Chang

行銷領域工作五年，其中四年幾乎每天都在想 SEO 的事。這裡寫我的筆記——不追流量、不堆關鍵字，只寫自己想讀的文章。

More about Albert →
Related