Core Web Vitals 完全攻略：SEO 核心指標 LCP、INP、CLS 優化實戰
Core Web Vitals 是 Google 定義的一組「真實使用者體驗」量化指標，目前由 LCP（載入）、INP（互動）、CLS（穩定）三項組成，數據來自真實 Chrome…
Google 的 Core Web Vitals：量化體驗的三個指標
Core Web Vitals 是 Google 定義的一組「真實使用者體驗」量化指標，目前由 LCP（載入）、INP（互動）、CLS（穩定）三項組成，數據來自真實 Chrome 使用者造訪紀錄，而非實驗室模擬。想完整理解這組 網站使用體驗核心指標 CWV 的來龍去脈，會發現它的設計邏輯一直圍繞著「使用者真實感受」這個主軸。根據 Google Search Central 的說明，2021 年 6 月這三項被正式列入頁面體驗（Page Experience）排名訊號，web.dev 的官方公告則記載，2024 年 3 月 12 日 INP 正式取代舊的 FID 指標。三項門檻分別是 LCP 2.5 秒、INP 200 毫秒、CLS 0.1。
重點先看：Core Web Vitals 三項門檻是 LCP ≤2.5 秒、INP ≤200 毫秒、CLS ≤0.1（根據 web.dev Core Web Vitals 官方文件），過了不保證排名提升，但沒過會在行動版被對手搶走點擊。
很多人把 Core Web Vitals 跟單純的「網站速度」劃上等號，這其實是誤會。一般講的速度多半指整頁載完要多久，網站速度優化的核心技巧 講的也是這件事，網頁速度 Page Speed 的定義與 SEO 影響 也常被拿來跟這組指標混為一談；Core Web Vitals 卻拆成三個互相獨立的面向：載入要夠快（LCP）、點了要立刻有回應（INP）、畫面不能亂跳（CLS）。一個網站可能整頁兩秒就載完，但 LCP 因為主圖延遲載入而破表；也可能 INP 漂亮，CLS 卻被廣告版位害到不及格。所以你無法用一個單一分數代表 Core Web Vitals，要看就是三項分開看。
真正會被忽略的關鍵是資料來源。這三個指標的數字來自 Chrome 使用者體驗報告（CrUX），也就是真實訪客的造訪紀錄。你在 網站速度測試工具 裡用 PageSpeed Insights 跑出來的 Lighthouse 分數，那是實驗室模擬，跟 CrUX 的真實數字通常對不上。這也解釋了為什麼你明明測出 90 分，搜尋排名卻沒動：因為你看的是模擬分數，Google 用的是真實造訪資料。把這層差異想清楚，比糾結單一數字重要太多。
這組指標的演進史也值得記一下。根據 Google Search Central 頁面體驗說明，2020 年 5 月 Google 首次預告頁面體驗訊號，把 Core Web Vitals 與行動相容性、HTTPS、無侵入性插頁廣告打包成同一組訊號。換句話說，Core Web Vitals 從一開始就被放進「整體頁面體驗」這個更大的框架裡，而非孤立單點。理解這個定位，你才會明白為什麼單獨把某一項修到滿分，有時排名連動都不動，因為它只是頁面體驗拼圖裡的一塊。
LCP 最大內容繪製：先抓對那張 hero 圖
LCP（Largest Contentful Paint，最大內容繪製）衡量的是視窗內最大元素完成繪製的那一刻，Google 門檻是 2.5 秒以內為「良好」，超過 4 秒為「差」，中間 2.5 到 4 秒屬於「需要改善」（web.dev LCP 官方文件）。注意，它測的是「使用者能看到主要內容」的那一刻，而非整頁載完，所以你的首圖與主標題載入順序才是決勝點。
一個共通現象是，大家拼命優化 footer、優化側邊欄，卻沒人動 hero 那張大圖。其實 LCP 抓的就是這張圖。當訪客打開頁面，最先映入眼簾的就是標題加上主圖，這一刻決定了他要不要留下來。如果這張圖是 3MB 的未壓縮 JPG，LCP 八成破 4 秒，後面再怎麼努力修都補不回來。先確認 LCP 元素到底是什麼再去動它，這個順序顛倒了就白做工。
WordPress 上拖慢 LCP 的元兇其實很固定：未壓縮的 hero 大圖、伺服器回應時間（TTFB）過高、阻擋轉譯的 CSS 與 JS、以及 LCP 元素被延遲載入。其中 WordPress 圖片優化流程 往往是收益最高的一塊。修法優先級我會這樣排：首圖轉 WebP 並壓縮、為圖片設 width 與 height 避免重排、把關鍵 CSS 內嵌、選回應快的主機或上 CDN 內容傳遞網路加速原理 分散資源。
| 指標 | 良好 | 需要改善 | 差 |
|---|---|---|---|
| LCP | ≤2.5 | 2.5–4.0 | >4.0 |
| INP（毫秒） | ≤200 | 200–500 | >500 |
| CLS | ≤0.1 | 0.1–0.25 | >0.25 |
有一點常被誤解：LCP 對「首次造訪」感受影響最大，直接關係到跳出率與停留時間。回訪者因為有瀏覽器快取，LCP 通常好看很多。所以如果你正在經營一個靠搜尋帶新流量的 WordPress 架站與 SEO 優化全攻略 站點，LCP 等於是給新訪客的第一印象分數。而決定新流量進不進得來的，往往是 關鍵字研究的工具與方法 是否做到位。把心力花在確認 LCP 穩定壓在 2.5 秒以內、再去顧內容，比死磕分數到 2.0 秒更划算。
LCP 改善對營收的影響有公開案例佐證：Vodafone 把 LCP 改善 31%，帶動銷售增加 8% [來源：web.dev〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。把 LCP 從不及格拉回門檻內，影響的不只是分數變綠，更是使用者願不願意在你頁面上完成購買。對新流量佔比高的網站來說，這正是 LCP 值得優先投資的硬道理。
「2.5 秒」這個數字其實不算嚴苛，它比較像一條及格線。壓到 2.0 秒不會讓排名往前擠，但卡在 3 秒以上，行動版訪客會開始跳出。想壓低 LCP，圖片壓縮工具實測推薦 與 WP Rocket 快取外掛設定教學 是兩個最快見效的切入點，前者解決最大的位元組，後者解決 TTFB。
先確定 LCP 元素是哪一個
修 LCP 之前，最該做的動作是先確定 LCP 元素到底是哪一個。很多站長跳過這一步直接改圖，結果改錯了圖、改的是側邊欄那張，分數一動也不動。判定方法有兩條路。第一條是開 Chrome DevTools 的 Performance 面板，錄製一次載入，在時間軸上找「Largest Contentful Paint」這個標記，它會直接點名是哪個元素。第二條更簡單，直接跑 PageSpeed Insights，診斷報告的「LCP 元素」一欄會列出是 hero 圖、是 H1 文字、還是背景圖。兩種方法選一種，三十秒內就能拿到答案。
拿到答案後，依元素類型決定修法。如果 LCP 元素是一張圖，就把這張圖轉 WebP、壓到合理位元組、補上 width 與 height，並且不要對它套用 lazy loading，因為延遲載入會把這張圖往後排。如果 LCP 元素是一段文字標題，多半是字型還沒載完導致繪製延遲，把關鍵字型預載（preload）就能改善。如果是背景圖，把它改成正規的 img 標籤加上 fetchpriority="high"，讓瀏覽器優先抓取。三種情境對應三種修法，搞錯類型等於白忙。
INP 互動延遲
INP（Interaction to Next Paint，與下一個顯示內容的互動）量測使用者點擊、輕觸、按鍵之後，網頁把畫面更新出來所花的全部時間，取整段造訪內最差的那一次當代表；良好門檻是 200 毫秒以內，超過 500 毫秒為差（web.dev INP 官方文件）。INP 在 2024 年 3 月取代了 FID，主因是 FID 只量第一次互動的延遲，一個網站只要第一次點擊快就能過關，後續卡到爆也沒事，這顯然不貼近真實感受。想知道 Google 為何從 FID 改用 INP 的完整脈絡，可以對照這項更替背後的衡量邏輯演進。
這裡要講清楚一個很多人搞混的地方：INP 觀察整段造訪內「每一次」互動的延遲，挑出最慢的那一次當代表。它比只量第一次的 FID 嚴格非常多。被記錄的互動有三種：滑鼠點擊、觸控輕觸、實體鍵盤按鍵；滑鼠懸停、縮放、捲動都不算。換句話說，你拼命優化捲動流暢度對 INP 一點幫助也沒有，要優化的是「點了之後多久有回應」這件事。
WordPress 上最常見的 INP 殺手很明確：過多第三方追蹤碼與廣告腳本、厚重主題或頁面編輯器的前端 JS、在主執行緒跑太多運算。常見的狀況是裝了一堆分析追蹤碼的購物站，INP 飆到 500 毫秒以上，使用者點「加入購物車」要等半秒才有反應，轉換率當然難看。修法不外乎這幾招：延後載入非必要 JS、拆分長任務、換掉肥大外掛與主題、用程式碼片段取代裝一堆功能外掛。
要不要為了 INP 換主題？答案多半是先別急。在動主題之前，先把 Lazy Loading 延遲載入做法、廣告腳本延遲、第三方追蹤碼精簡這些低風險動作做完，多半能把 INP 壓回 200 毫秒以內。真的做完還是破表，再來評估換主題或換 WordPress 佈景主題推薦比較 與主機。順序錯了，你可能花一筆錢換了主題，結果發現瓶頸根本不在主題。
如果你正在經營小型電商，INP 的影響會被放大。購物車、結帳、篩選器這些操作全是高頻互動，任何一處卡頓都可能讓訂單流失。想在 RWD 響應式電商網頁設計 之外再顧好互動流暢度，建議把結帳流程的 JS 精簡到最低，並把分析碼延後到頁面可互動之後再載入。商品頁的 網址 URL 結構 也要維持乾淨，避免參數堆疊拖累檢索與載入。
而且這不是理論推測。redBus 改善了網站的 INP 之後，銷售增加了 7% [來源：web.dev〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。對高互動的電商頁面來說，「點了馬上有回應」直接折算成訂單數字，這也是為什麼 INP 不該被放到最後才處理，只要卡到結帳或加車流程，流失就會在你看不到的地方發生。
INP 也是三項裡最難自己測的一個，因為它高度依賴真實使用者造訪。實驗室分數只能給你方向，真正的成績要看 CrUX 與 Search Console 的 Google Search Console 完整設定 核心網頁指標報表。若你還沒接觸過這套工具，先看一篇 Google Search Console 入門介紹 會比較容易上手。這也意味著，新站剛上線時根本沒有 INP 資料，要等流量進來、CrUX 累積夠多樣本才看得到。新站站長別急著對 INP 焦慮，先把架構做好。
CLS 累計版面配置轉移
CLS（Cumulative Layout Shift，累計版面配置轉移）量化整段造訪期間「畫面沒有預警地移位」的總量，門檻是 0.1 以內為良好、超過 0.25 為差（web.dev CLS 官方文件）。會讓使用者點錯按鈕、找不到閱讀位置的那種版面跳動，就是它要抓的問題。
有個計算細節很值得理解：CLS 算的是「位移幅度乘上影響範圍」的累計值，不是次數。所以一次大跳動的殺傷力，遠比很多次小跳動來得大。這跟你直覺可能不一樣。你以為「只有一點點跳」沒事，結果那一次大跳把 CLS 直接頂到 0.3。最常見的元兇也就那幾個：圖片與廣告沒有預留空間、字型載入造成的 FOIT 與 FOUT、動態插入的內容把既有元素推開。
修法非常具體，而且成本通常很低：為所有圖片與 iframe 設 width 與 height、為廣告版位預留固定尺寸、避免在讀者視窗範圍內動態插入內容。換個角度想，CLS 是三項裡通常最好修的一項，成本最低、效益明確，建議優先處理。一個下午把全站圖片補上尺寸屬性，紅字往往就清掉大半，搭配 Smush 圖片壓縮與延遲載入 這類外掛還能順手把圖片顧好。這也是新手適合從 CLS 開刀的原因。
字型造成的跳動則比較隱性。瀏覽器載入網路字型時，會先用替代字型顯示，字型下載完再切換，這個切換會讓版面位移。解法是把 Google Fonts 本機託管並預載，可參考 本機託管 Google Fonts 加速 的做法。廣告版位則建議直接在版面裡預留一個固定高度的容器，廣告進來時就不會把下方內容往下推。這兩個動作做起來都不複雜，效益卻很直接。
Core Web Vitals 對 SEO 排名的實際權重
Core Web Vitals 是 Google 排名訊號之一，但官方把它定位為「內容相關性相近時的體驗決勝點」，權重低於內容相關性與反向連結（Google Search Central 頁面體驗說明）。三項都壓在及格線內不會自動把名次往前推，但在競爭激烈的查詢裡，它會決定誰拿到點擊。
這裡要戳破一個流傳很廣的說法：把 Core Web Vitals 當成「通過就會排名變好」的萬靈丹。實際情況是，Google 自己的說明寫得很清楚，當兩個頁面內容與權威度接近時，體驗較好的一方勝出。翻成白話就是 tie-breaker，同分時才上場的裁判。如果你的內容本來就排不上去，把 Core Web Vitals 修到滿分也擠不進首頁。很多站長卡在「分數達標卻排名不動」，多半是因為一開始就把它當成了主力排名工具，而真正的瓶頸出在內容與連結。與其把預算全壓在自然搜尋，搭配 SEA 關鍵字廣告的優勢介紹 做短期曝光互補，會是更務實的配置。
真正的 SEO 順序應該是：先確認內容相關性與 站外 SEO 與反向連結建立 這些高權重項目到位，再把 Core Web Vitals 當成及格門檻顧好。講到連結，站內站外導入導出四大類連結的全面解析 能幫你釐清哪一類連結才真正搬動排名。確認三項都過門檻、再把資源投到 站內 SEO 內容與技術優化 與連結，會比糾結分數微調帶來更高的 ROI。
行動版的體驗權重特別高。行動版流量在多數查詢佔比已過半，行動版分數落後等於直接把點擊讓給對手。Google 在 2020 年宣布行動優先索引時，已有 70% 的網站完成切換，並於 2023 年 10 月宣告行動優先索引全面完成（Google Search Central 行動優先索引公告）。這代表 Google 看的分數幾乎就是你手機版那一份。所以你在 響應式網頁設計 RWD 上看到的手機版分數，才是你該認真對待的那一個，電腦版可以暫時擺後面。順帶一提，確認行動版頁面沒有被 noindex 設定 擋掉也很關鍵，否則分數再好也不會被計入。
間接影響其實比直接影響更實際。載入快、互動順、不亂跳，跳出率會降、停留時間會升，這些行為訊號會回頭加強排名。這個推論是業界普遍看法，不是 Google 公開背書的數字，但它符合常理：使用者用得順手，就會多停留、多互動、多分享。已有公開案例能佐證這個方向：The Economic Times 在通過 Core Web Vitals 門檻後，整體跳出率改善了 43% [來源：web.dev〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。體驗順暢也會強化 數位行銷入門 談論的品牌信任累積，長期對整體 SEO 搜尋引擎優化完整指南 成效有加乘作用。
如果你的網站分數已經全綠，排名還是沒動，答案很簡單：把焦點轉回 關鍵字搜尋意圖的判讀 與 Google 搜尋演算法運作規則 背後真正高權重的因子。若想再往源頭追，拆解搜尋意圖與高排名的關係 會告訴你為什麼內容對不對題比分數漂亮更重要。Core Web Vitals 過了門檻之後，它的影響就讓位給內容與連結了，繼續微調分數邊際效益很低。
Core Web Vitals 與其他排名訊號的優先級矩陣
把 Core Web Vitals 放進整體 SEO 投資清單裡比較，才看得出它真正的份量。底下這張矩陣把常見的排名訊號依「權重高低」與「見效快慢」兩個維度分類，幫你決定資源該先投到哪裡。權重指對排名的直接搬動力，見效快慢指從動手到看到排名變化的時間。
| 象限 | 代表項目 | 策略建議 |
|---|---|---|
| 高權重、見效慢 | 內容相關性、反向連結、E-E-A-T | 長期主力投資，持續累積 |
| 高權重、見效快 | 關鍵字搜尋意圖命中、標題與中繼描述 | 優先處理，ROI 最高 |
| 低權重、見效快 | CLS 修復、HTTPS、無侵入性插頁廣告 | 當及格門檻快速清掉 |
| 低權重、見效慢 | Core Web Vitals 的 LCP 與 INP 微調 | 過門檻即可，勿過度投入 |
從矩陣可以看出，Core Web Vitals 的 LCP 與 INP 落在「低權重、見效慢」這一格，過了門檻就該收手；CLS 因為見效快，落在「低權重、見效快」，一個下午清掉。真正會移動排名的，是左上與右上兩格的內容、連結與搜尋意圖命中。分數過門檻之後，心力立刻轉到右上格的搜尋意圖與標題優化，長期則持續投資左上格的內容與連結，這是唯一能穩定站穩排名的根基。
用 PageSpeed Insights 與 Search Console 量測分數
量測分兩種：PageSpeed Insights 用實驗室模擬給你逐項診斷與修法，Google Search Console 的「核心網頁指標」報表則顯示真實使用者的整站趨勢，兩者要搭配看才準。只看其中一種都會誤判。
PageSpeed Insights 的頁面分上下兩層。上方欄位是 CrUX 真實資料，代表使用者實際感受；下方欄位是 Lighthouse 模擬分數，代表診斷細節（PageSpeed Insights 官方說明）。很多人只看下方那個漂亮的 90 分就以為沒事，結果上方 CrUX 顯示 LCP 不及格，這就是模擬與真實的落差。行動裝置與電腦版分數會不一樣，行動版通常較差，必須分開檢查並以行動版為準。若想把量測觀念延伸到 AI 搜尋領域，參考 GEO 與 AI 搜尋課程推薦 能補上另一塊拼圖。
| 項目 | PageSpeed Insights 上方 CrUX | PageSpeed Insights 下方 Lighthouse | Search Console 核心網頁指標 |
|---|---|---|---|
| 資料來源 | 真實 Chrome 使用者 | 實驗室模擬 | 真實 Chrome 使用者 |
| 呈現方式 | 單一網址 | 單一網址 + 診斷建議 | 整站網址分組 |
| 更新頻率 | 28 天滾動 | 即時模擬 | 28 天滾動 |
| 用途 | 看真實感受 | 找問題與修法 | 看整站趨勢與分群 |
Search Console 的「核心網頁指標」報表會把整站網址依良好、需要改善、差分成三組，告訴你哪些類型的頁面要優先處理（Search Console 官方說明）。比方說它可能顯示你所有「商品頁」的 LCP 都不及格，但你「部落格文章」卻全綠，這就給了你非常明確的下手方向。這個分群視角是 PageSpeed Insights 給不了的。對經營品牌的站點來說，把體驗顧好再結合 SERPO 技巧替品牌建立信任感，能讓搜尋結果的點擊表現更穩。
分數會波動，這點要先有心理準備。CrUX 以 28 天滾動資料呈現，今天修了明天看不到結果是正常的，建議以週為單位追蹤趨勢。常見的陷阱是改一個地方就隔天開 PageSpeed Insights 看，然後失望地以為沒效，其實只是資料還沒更新。如果你想在 爬取預算與搜尋引擎抓取效率 之外，多掌握一個長期觀測點，Search Console 報表是最省事的一個。而在 AI 搜尋漸成主流的此刻，留意 Agentic Browsing 對網站的檢索影響 也是另一個值得長期追蹤的面向。
實務上我會建議把這兩個工具搭配用：PageSpeed Insights 用來找單一頁面的具體問題，Search Console 用來看整站哪一類頁面最需要救。再搭配 Search Console 實戰檢索技巧，就能把檢測 → 診斷 → 修復 → 追蹤的迴圈跑起來。
CrUX 與 Lighthouse 分數落差的成因
很多站長第一次看到 PageSpeed Insights 上下兩欄分數差很多，會以為工具壞了。其實 Lighthouse 在固定設備、固定網路下跑模擬，測的是「理想環境裡這個頁面能跑多快」；CrUX 則混入了用舊手機、連慢速行動網路、在訊號差的捷運裡造訪的真實訪客，測的是「真實世界裡實際感受到的速度」。真實世界的設備與網路條件遠比實驗室嚴苛，所以 CrUX 通常比 Lighthouse 差。
讀分數時有個判斷原則：當 CrUX 與 Lighthouse 都不及格，問題出在頁面本身，照 Lighthouse 的診斷修就對。當 Lighthouse 漂亮但 CrUX 不及格，問題多半出在真實使用者的設備與網路，這時要檢查是不是有大量行動訪客用低階機造訪，針對他們做資源瘦身，例如更積極地延後載入、砍掉非必要字型與腳本。當 CrUX 漂亮但 Lighthouse 不及格，這種情況少見，多半是 Lighthouse 模擬環境較嚴或頁面剛改過、CrUX 還沒更新，以 CrUX 為準即可。三種情境三種對策，先判斷屬於哪一種，再決定要不要動手。
另外有一個門檻常被忽略：CrUX 要累積足夠樣本才會顯示數字。一個流量太低的頁面，PageSpeed Insights 上方欄位會直接顯示「無資料」，這純粹是樣本不足，與頁面快慢無關。新站或冷門頁面遇到這種情況很正常，不必焦慮，先靠 Lighthouse 給方向，等流量起來、CrUX 有資料了再做精準判斷。
WordPress 站長的修復優先級
WordPress 上的修復順序按修改難度與見效速度排列：CLS 設尺寸屬性就能清紅字，LCP 要動圖片與快取屬中等工作量，INP 要碰第三方腳本最後再做。
| 指標 | 見效速度 | 主要修法 | 風險 |
|---|---|---|---|
| CLS | 最快（一個下午） | 圖片與 iframe 補 width/height、廣告版位預留固定尺寸 | 極低 |
| LCP | 中等 | 首圖轉 WebP 壓縮、快取外掛降 TTFB、關鍵 CSS 內嵌、上 CDN | 中 |
| INP | 最慢 | 延後非必要第三方追蹤碼、刪閒置外掛、精簡頁面編輯器前端 JS | 中高（牽動分析與廣告） |
| 通用底線 | 持續 | 回應快的主機、快取、Gzip/Brotli、最小化 CSS/JS、減少外部請求 | 低 |
實務上接手過一個匿名醫美診所的 WordPress 站，月 sessions 26,118，行動流量佔 78.4%，狀況正是行動版 LCP 與 CLS 同時失敗：hero 圖與醫師照沒壓、字型阻塞繪製、圖片缺尺寸屬性、Meta Pixel 與 chat widget 搶主執行緒，一整串問題疊在一起。這類站的 LCP 元素通常就是文章首圖或 hero 區塊的主視覺，因為佈景主題預設會把首圖延遲載入，結果最重要的那張圖反而最晚出現。CLS 的問題則多半集中在兩處：一是無尺寸屬性的圖片在載入時把下方文字往下推，二是廣告版位在請求回來後才撐開高度。前者在用古騰堡編輯器插入圖片時最常發生，若媒體庫的圖沒有正確的中繼資料，前端就不會自動帶出 width 與 height；後者則是因為多數廣告外掛預設不預留空間，廣告回填的瞬間才把版面撐開。這兩類問題的共通點是修法都極簡單，但需要逐頁確認，內容站頁面一多就容易漏掉幾篇。動手前我先做兩個三十秒的確認動作省下大量白工：用 DevTools 的 Performance 面板錄一次行動版載入，確認 LCP 元素是首圖而非 H1 標題，再用 Network 面板看主文件請求的 TTFB 落點。這個站的 TTFB 正常但 LCP 仍高，瓶頸確認落在圖片與字型這端，所以修法順序才排對，沒有一開始就花時間改錯地方。
那波的實際工作與量測結果如下，時間是 2025 年 Q1。我壓縮了 hero 圖與醫師照、把圖改 WebP、預載主字體、延後 Meta Pixel 與 chat widget、移除未用 CSS、補上圖片尺寸、最後調 WP Rocket 的 critical CSS，過程中用的是 WP Rocket 3.16.4 與 ShortPixel 5.6.2。量測結果：行動 LCP 從 4.9 秒降到 2.3 秒（來源：PageSpeed Insights 實測 2025-03-25）；CLS 從 0.19 降到 0.03（來源：PageSpeed Insights 實測 2025-03-25）；PageSpeed Insights 行動 Performance 從 43 提升到 84（來源：PageSpeed Insights 實測 2025-03-25）；Search Console 核心網頁指標裡 failed 的網址數從 128 降到 14（來源：Google Search Console 核心網頁指標報表，28 天資料）；高意圖頁的轉換率從 1.3% 提升到 1.7%（來源：GA4 landing page 報表）。INP 在這類醫美內容站本來就不是最痛的，因為互動集中在選單與聯絡表單，所以我把它放到最後階段一併檢視。因為這站同時用了快取外掛與 CDN，記得在 CDN 端也清除舊快取，否則前端拿到的還是未壓縮的舊圖，分數自然不動。
但要老實說哪裡沒效：速度變好之後排名只有小幅上升，不能把整體約 12.6% 的流量成長全歸因給 Core Web Vitals，同期投放的廣告與醫美旺季的季節性也有影響，三者交織在一起無法拆開。把 Core Web Vitals 修好，更準確的定位是移除體驗與轉換的阻力，而不是直接兌換排名。一個容易踩到的驗收陷阱是：修改完隔天就開 PageSpeed Insights 看分數，發現沒變就以為沒效。其實 CrUX 是 28 天滾動資料，今天動的工最快也要一兩週才會反映在上方欄位；想即時確認修改方向對不對，應該對照下方 Lighthouse 的模擬數字與 DevTools 實測，等 CrUX 資料更新後再做最終判斷。
不過有個限制必須先講清楚：速度改善很難單獨換成排名跳升。上面那些數字變綠之後，自然流量大概在八週後成長約 10-20%，但這段成長與同期內容、連結的累積交織在一起，無法全部歸因給速度。把 Core Web Vitals 修好，更準確的定位是移除體驗與轉換的阻力。動手前先寫清楚這三件事最有價值：哪一個指標失敗、瓶頸具體出在哪一段、修完之後是否真的在 field data 通過門檻。把這三點釐清，才知道這波優化是該收手、還是該繼續往下挖。
實作層面，CLS 幾乎零風險：進 WordPress 媒體庫確認每張圖都有正確尺寸屬性，把廣告版位與嵌入影片用固定高度容器包起來即可，過程中可搭配壓圖外掛順手補上尺寸。LCP 要動的東西較多，首圖轉 WebP 與 JPG、PNG 格式比較 後的格式是第一步；TTFB 偏高就啟用 WordPress 快取外掛實測比較，原理可參考 快取 Cache 的運作原理與設定；流量大了再上 CDN。INP 最花時間，因為它牽涉與分析、廣告、行銷自動化綁在一起的第三方腳本。先用 PageSpeed Insights 的「減少主執行緒工作」與「減少 JavaScript 執行時間」兩項診斷找出最肥的腳本，再決定哪些延後、整合或刪除，過程中參考 WordPress 網站加速效能外掛 與 WordPress 必裝外掛清單，避免為了解一個問題又裝一堆新外掛。
主機與主題是兩個常被低估的變數。回應慢的主機會把 TTFB 拉高，連帶拖垮 LCP 與 INP。如果你用的是入門共用主機，升級到 虛擬主機類型比較選擇 裡的雲端或 VPS 方案，例如 Cloudways 雲端主機架站、SiteGround 或 A2 Hosting，往往比優化外掛更有感。主題則看 Astra Pro 主題效能評測 這類輕量選項，前端 JS 越少，INP 越好看。
頁面編輯器是另一個 INP 隱形殺手。Elementor、Divi 這類編輯器會在 frontend 留下不少 JS 與 DOM 節點，偏偏這正是 INP 最怕的東西。如果你重度使用 Elementor 頁面編輯器教學 或其他 WordPress 頁面編輯器比較 裡的工具，記得到設定裡關掉用不到的 widget 與動畫，把前端產出的程式碼量壓到最低。
從更大的角度看，Core Web Vitals 優化不該是獨立工程，它跟你整體的 技術性 SEO 架構優化 與 SEO 友善的網站架構規劃 是同一件事。網站變慢往往不是單一原因，是架構、外掛、主機、圖片層層疊加的結果。與其頭痛醫頭，不如從 網站變慢的瓶頸診斷與解法 著手，把整條效能鏈一次理順。
新站與低流量站的 Core Web Vitals 策略
新站與低流量站會遇到一個尷尬狀況：你照著優化做完，卻在 PageSpeed Insights 上方欄位看到「無資料」，在 Search Console 核心網頁指標報表也看不到任何數字。原因單純是 CrUX 還沒累積到足夠的真實訪客樣本來產生統計。CrUX 對樣本數有最低門檻，流量不夠的頁面就是拿不到分數。
對這類站點，策略要調整。第一，量測主要靠 Lighthouse 模擬分數與 DevTools，把模擬數字當成「方向」而非「成績」，因為 Google 排名用的是 CrUX，而你還沒有 CrUX 資料。第二，把力氣放在已知有效的通用底線：圖片壓縮與尺寸屬性、快取啟用、第三方腳本精簡，這些動作無論有沒有 CrUX 資料都該做。第三，別為了看不到的分數焦慮而過度投資，把更多心力放在能直接累積流量與連結的內容產製上。等流量進來、CrUX 開始有資料，再回頭做精準優化。
判斷自己的站是否進入「有 CrUX 資料」的階段，最直接的方式是在 PageSpeed Insights 輸入首頁網址，看上方欄位是否出現 LCP、INP、CLS 三項數字。三項都顯示數字，代表你的站已被 CrUX 收錄，可以開始認真追蹤。若仍顯示「無資料」，代表樣本不足，繼續衝流量與內容才是正解。把這個檢查當成每月一次的例行確認，能避免你對著空分數白操心。
Core Web Vitals 常見問題
FAQ 集中在三類：分數達標排名不動、FID 跟 INP 差別、實驗室分數跟真實感受不同。以下逐一拆解。
Q：Core Web Vitals 分數都過了，排名還是沒動？
A：它不是主力排名要素。官方定位為 tie-breaker，過門檻後影響讓位給內容相關性與反向連結。把心力轉到 提升 Google 排名的關鍵原因 與 E-E-A-T 經驗權威信任原則，效益更高。
Q：FID 跟 INP 差在哪？
A：FID 只量第一次互動的延遲，INP 量整段造訪內最差的那一次，更貼近真實感受。INP 已於 2024 年 3 月取代 FID（web.dev 公告）。
Q：PageSpeed Insights 分數跟實際感受為什麼不一樣？
A：因為下方是 Lighthouse 實驗室模擬，真實感受要看上方 CrUX 欄位與 Search Console 報表。對自學吃力的朋友，知識衛星 《SEO 排名攻略學》線上課 這類系統化教材能幫你把觀念一次補齊。
Q：CrUX 顯示無資料怎麼辦？
A：意思是訪客樣本還沒累積到 CrUX 能給出數字的程度，通常發生在新網站或頁面流量偏低的時候。過渡期靠 Lighthouse 與 DevTools 的模擬結果當參考，先把壓縮圖片、快取、第三方腳本基本功顧好，同時持續產出內容帶進流量，等 CrUX 顯示數字後再做精準調校。
如果你的網站最近遇到排名下滑，先確認是不是 Google 排名下滑的急救方法 裡提到的其他原因，例如 301 與 302 轉址 SEO 影響 或 Canonical 重複內容處理 出了狀況；若問題出在流量而非單一頁面，再對照 網站流量下滑的恢復策略 逐項排查。體驗指標只是眾多因子之一，把它擺對位置才不會白忙一場。