去年我接手一個朋友的 WordPress 商品站，手機版 PageSpeed 分數 34 分。我先把首圖從 2.3MB 換成 180KB 的 WebP，接著關掉三個沒在用的外掛——兩週後 Search Console 的「網站使用體驗核心指標」報表就從紅色轉成黃色。做網站速度優化之前，你得先知道 Google 現在到底在量什麼、門檻在哪裡，否則很容易花一堆力氣改到不影響評分的地方。這篇把 Core Web Vitals 的三項指標、測量方式，以及 WordPress 上真正有效的修法，一次講完。
📌 本文重點
- Core Web Vitals 現行三項指標是 LCP、INP、CLS；INP 已於 2024 年 3 月 12 日正式取代 FID，FID 已從計畫中除役。
- Google 官方的「良好」門檻：LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，且以第 75 百分位數的實際使用者資料判定。
- PageSpeed Insights 上半部的真實使用者資料（CrUX）取過去 28 天，下半部的 Lighthouse 分數只是模擬環境，兩者不一致是正常的，決策要看前者。
- WordPress 上 LCP 通常卡在主機 TTFB 與首圖，INP 卡在肥大的 JS 與過多外掛，CLS 幾乎都來自沒設 width/height 的圖片、字體置換和動態插入的廣告版位。
- 修的順序建議是 CLS → LCP → INP，因為 CLS 成本最低、INP 最需要動到程式與外掛結構。
Core Web Vitals 三項指標各自量什麼
先講最容易搞錯的一件事。很多中文教學到現在還在寫 FID（First Input Delay），但 FID 已經在 2024 年 3 月 12 日被 INP 正式取代，並從 Core Web Vitals 計畫中除役。Google 在官方公告裡寫得很清楚，FID 當天就從 Search Console 移除，其他工具則給了六個月緩衝期（資料時間：2024-03-12，來源：web.dev 官方公告）。你如果還在照 FID 調校，等於在修一個已經不存在的分數。
現行三項指標分別對應載入、互動、視覺穩定三個面向。LCP（Largest Contentful Paint）量的是「畫面上最大的那塊內容多久畫出來」，通常是首圖或大標題。INP（Interaction to Next Paint）量的是整個瀏覽過程中，所有點擊、觸控、鍵盤操作到瀏覽器畫出下一幀的延遲——注意，它看的是整段造訪期間的所有互動，不像 FID 只看第一次。CLS（Cumulative Layout Shift）量的是版面在你眼前跳動的累積幅度。
官方門檻長這樣：
| 指標 | 量什麼 | 良好 | 需要改進 | 不良 |
|---|---|---|---|---|
| LCP | 最大內容繪製時間（載入） | ≤ 2.5 秒 | 2.5–4.0 秒 | > 4.0 秒 |
| INP | 互動到下一次繪製（回應速度） | ≤ 200 毫秒 | 201–500 毫秒 | > 500 毫秒 |
| CLS | 累積版面配置位移（穩定度） | ≤ 0.1 | 0.1–0.25 | > 0.25 |
資料時間：2026-07，來源：web.dev — Web Vitals、web.dev — Interaction to Next Paint (INP)。
還有一個常被忽略的規則：三項指標都是取「第 75 百分位數」，而且行動裝置與桌機分開計算。意思是你不能拿平均值交差，必須讓四分之三的訪客都落在良好範圍才算過關。我看過太多人拿自己 Mac 上的測試結果說「明明很快」，然後 CrUX 資料裡手機端 LCP 是 4.8 秒。
怎麼測：實驗室資料與真實使用者資料的差別
打開 PageSpeed Insights 你會看到上下兩塊，這兩塊是完全不同的東西，搞混會讓你優化錯方向。
上半部標著「探索實際使用者的使用體驗」，資料來自 CrUX（Chrome 使用者體驗報告），是真實 Chrome 使用者在各種手機、各種網路下的實測結果，取過去 28 天的滾動資料、以第 75 百分位數呈現（來源：Google PageSpeed Insights 官方說明）。下半部的效能分數則是 Lighthouse 在 Google 機房用模擬手機（行動版模擬 Moto G4 等級裝置）跑出來的實驗室資料。
簡單記法：Google 排名參考的是上半部的真實資料，下半部那個 0–100 分只是給你除錯用的。我自己的習慣是，上半部決定「該不該修」，下半部的診斷清單決定「要修哪裡」。如果上半部顯示「沒有足夠的實際速度資料」，代表這頁流量太少，CrUX 會退回整站（origin）層級的資料，這時候就只能靠 Lighthouse 加自己的判斷。
另一個必看的地方是 Search Console 左側的「網站使用體驗核心指標」報表。它同樣吃 CrUX 資料，但會把體驗相似的網址自動分組，整組共用一個狀態，而且是取三項中表現最差的那一項當作該組的判定（來源：Search Console 說明中心）。這代表分組裡只要有一種頁面型態爛掉，整組都會被拉下來——找出那個「拖後腿的模板」，通常比逐頁修划算得多。
修 LCP：主機、首圖、字體、快取
WordPress 的 LCP 有一半以上是輸在起跑點，也就是 TTFB（伺服器回應第一個位元組的時間）。共用主機在尖峰時段 TTFB 破一秒是家常便飯，剩下 1.5 秒要畫完整張首圖幾乎不可能。如果你的 TTFB 長期超過 800 毫秒，先換主機，其他優化都是在補破網。選主機的取捨我另外整理過一份 WordPress 虛擬主機的比較與挑選指南，可以照自己的流量規模對照。
接下來是首圖。三個動作按投報率排序：第一，把首圖轉成 WebP，寬度控制在 1200–1600px、檔案壓到 200KB 以內；第二，首圖絕對不要 lazy load——WordPress 5.5 之後預設會對圖片加 loading="lazy"，第一屏的圖被加上去反而會拖慢 LCP，要改成 loading="eager" 並加上 fetchpriority="high"；第三，如果首圖是背景圖或由 JS 載入，補一行 <link rel="preload" as="image"> 讓瀏覽器提早開始下載。
字體是第三個常見兇手。中文網頁最忌諱整包載入完整字重的思源黑體，動輒好幾 MB。實務上我會只保留兩個字重、加上 font-display: swap，並且對關鍵字體檔做 preload。真的要用中文網頁字型，記得挑有做子集化（subset）的版本。
快取外掛放最後講，因為它是放大器不是解方。WP Rocket、LiteSpeed Cache、W3 Total Cache 都能把 TTFB 從幾百毫秒壓到幾十毫秒，但前提是你的主機本身不能太差、頁面本身不能太肥。快取只會讓「已經合理的頁面」變快，不會讓一個塞了 40 個外掛的頁面變好。
修 INP：JS、外掛、第三方腳本
INP 是三項裡最難修的，因為它跟「你裝了什麼」直接綁定。使用者點一個按鈕，瀏覽器主執行緒如果正在跑別的 JavaScript，這個點擊就得排隊——排隊的時間全部算進 INP。
WordPress 站最典型的三個來源，我按遇到的頻率排：
- 頁面建構器與過多外掛。Elementor、WPBakery 這類建構器本身就會塞不少 JS；再加上每個外掛都在前台載自己的 CSS/JS，一個首頁跑 30 個請求很常見。我的做法是打開瀏覽器開發者工具的 Coverage 面板，看哪些 JS 檔案「載入了但幾乎沒用到」，再用 Asset CleanUp 或 Perfmatters 這類外掛做逐頁停用。
- 第三方腳本，尤其是廣告與追蹤碼。GA4、Meta Pixel、Google Ads、各種熱圖工具，每一個都在搶主執行緒。能延後的就用
defer，非必要的就砍掉——我遇過同一個站同時裝了 GTM、GA4 外掛和主題內建追蹤，等於量了三次。 - 長工作（Long Tasks）沒有切開。如果你有自訂 JS，任何超過 50 毫秒的工作都該想辦法拆分，或用
requestIdleCallback挪到閒置時段執行。
老實說，INP 的優化最常見的結論是「砍外掛」，而不是「加一個優化外掛」。每砍一個沒在用的外掛，你少的不只是 JS，還有它連帶的 CSS、資料庫查詢和更新風險。如果你正在盤點自己的外掛清單，可以順便看一下 新手最常踩到的網站設計地雷，很多效能問題其實在架站當下就種下了。
修 CLS：圖片尺寸、字體置換、廣告版位
CLS 是三項裡最好修的，通常一個下午就能從紅色拉到綠色。它的成因很集中，就三種。
第一種是圖片沒有指定 width 和 height。瀏覽器不知道圖多高，就先當它是 0，等圖載完再把下面的文字往下推——這一推就是位移。WordPress 上傳的圖預設會帶尺寸屬性，但很多主題或頁面建構器會在輸出時把它拿掉，記得用「檢視原始碼」實際確認一次。用 CSS 的 aspect-ratio 也能達到同樣效果。
第二種是字體置換造成的版面跳動。網頁先用系統字顯示、自訂字體載入後再換掉，如果兩種字的字寬差很多，整段文字就會重排。中文站尤其明顯。解法是對主要字體做 preload，並在 @font-face 裡用 font-display: swap 搭配 size-adjust 微調回退字體的度量。
第三種是動態插入的廣告版位與彈窗。AdSense 自動廣告最容易出事——它會在文章中間硬塞一個版位，把下面的內容整片推下去。做法是改用手動版位，並且在外層 div 先用 CSS 預留最小高度（例如手機 250px、桌機 280px），廣告沒載到就留白，也好過把讀者正在看的段落推走。電子報彈窗、Cookie 提示條同理，一律用 position: fixed 疊在上層，不要擠壓文件流。
先做哪一項？優先順序與取捨
如果三項都不及格，我的建議順序是 CLS → LCP → INP。理由很現實：CLS 修起來最便宜（補尺寸屬性、預留廣告高度，不用動架構），LCP 次之（換圖、開快取，可能要換主機），INP 最貴，因為它幾乎一定要動到外掛結構甚至主題。
但如果你的網站有明確的商業目的，順序要跟著錢走。電商或訂單型網站，優先修結帳與商品頁的 INP；內容型網站流量多來自搜尋，優先修文章模板的 LCP。先修「賺錢的那個頁面模板」，比先修分數最低的頁面更有意義。
最後講取捨，這是我最想提醒的一點。我看過有人為了讓分數變綠，把文章裡的所有圖片刪光、把 AdSense 全部拿掉、把留言功能關掉——分數是 98 分了，但停留時間和廣告收入一起腰斬。Core Web Vitals 是排名的輔助訊號，不是排名本身；當內容品質和跑分衝突時，選內容。合理的做法是先問「這個元素有沒有創造價值」，有價值就想辦法讓它載得更聰明（延後、預留空間、換格式），而不是直接砍掉。順帶一提，優化前先算清楚投入產出也很重要，這部分可以參考 自架網站的成本結構拆解，別為了 5 分的差距去升級一台你用不到的主機。
還沒開始架站、正在挑主機與平台的人，可以先看過 網站架設的主機、網域、平台全攻略——一開始選對，後面能少修一半的效能問題。
常見問題（FAQ）
Q：FID 還要不要看？
A：不用了。FID 已於 2024 年 3 月 12 日被 INP 取代並正式除役，Search Console 當天就移除該指標。現在只需要關注 LCP、INP、CLS 三項。
Q：PageSpeed 分數 90 分以上，Search Console 卻顯示「需要改進」，為什麼？
A：因為兩者資料來源不同。PageSpeed 的分數是 Lighthouse 模擬環境的實驗室資料，Search Console 用的是 CrUX 真實使用者資料（過去 28 天、第 75 百分位數）。你的訪客可能用比較舊的手機或比較慢的網路，實測就會比模擬差。以真實資料為準。
Q：裝一個快取外掛就能三項都達標嗎？
A：不會。快取主要改善 TTFB 與 LCP，對 CLS 幾乎沒幫助，對 INP 的幫助也有限——INP 取決於你載了多少 JavaScript，快取不會讓 JS 變少。CLS 和 INP 都需要手動處理。
Q：改完之後多久會反映在 Search Console？
A：CrUX 是 28 天滾動資料，所以通常要等三到四週才會完整反映。改完隔天先用 PageSpeed 的 Lighthouse 那半部確認方向對不對，再等真實資料跟上。
Q：Core Web Vitals 對 SEO 排名影響有多大？
A：它是頁面體驗訊號的一部分，屬於加分項而非決定性因素。在內容品質接近的情況下，速度較好的頁面有優勢；但一篇速度慢卻真正解決問題的文章，仍然會贏過一篇秒開的空洞內容。
資料來源：web.dev — Web Vitals｜web.dev — INP｜web.dev — INP becomes a Core Web Vital｜Google PageSpeed Insights 說明｜Search Console 網站使用體驗核心指標報表（查證時間：2026-07-22）
