Core Web Vitals 2026 完整治理指南：LCP / INP / CLS 三大指標 + 4 條優化路徑 + 3 個 ROI 試算 — 中小企業老闆網站 SEO 突破 60 分頂的最後一哩

最近我們在幫一家中部製造業客戶做 SEO 健檢，第一件事就是把 PageSpeed Insights 跑一遍。結果跟去年比有個很明顯的趨勢——超過六成卡在 INP > 200ms，LCP 反而沒那麼糟。這跟 2025 年 3 月 Google 正式把 INP 替換掉 FID 之後的市場現況一致：Google 官方公告（INP 從實驗指標轉正、FID 退役），讓 INP 變成 2026 的最大殺手。

如果你是中小企業老闆、或公司的行銷主管 / IT 主管，這篇文章直接給你三件事：第一，2026 最新的 LCP / INP / CLS 三大指標通過門檻，跟 Chrome UX Report 五月最新通過率對照；第二，四條優化路徑的真實成本，從 5 萬到 80 萬都有；第三，三個不同情境的 ROI 試算，讓你判斷該不該動手、什麼時候動手、找誰做。

先丟一個數字。根據 Chrome UX Report 2026 年 5 月最新統計，全球只有 55.9% 的網站能同時通過三個 Core Web Vitals 門檻。其中 INP 通過率 86.6%、LCP 68.6%、CLS 81.3%——LCP 才是真正的瓶頸。台灣站點普遍更慘，我們經手過的案子裡，平均通過率大約落在 35-45% 之間，比全球平均低 10-20 個百分點。

LCP / INP / CLS 三大指標的真實意義（給老闆與行銷主管的白話版）

先把三個英文縮寫翻譯成人話。LCP（Largest Contentful Paint，最大內容繪製）量的是「使用者看到主視覺出現要等多久」；INP（Interaction to Next Paint，互動到下一次繪製）量的是「使用者按了按鈕、選了選單之後，畫面要多久才有反應」；CLS（Cumulative Layout Shift，累積版面位移）量的是「載入過程中畫面有沒有亂跳，把使用者快點到的按鈕忽然推走」。

這三個指標 Google 設計的時候其實是給「使用者體驗」打分數，不是給工程師看的。LCP 太慢——使用者覺得網站卡；INP 太慢——使用者覺得網站當機；CLS 太亂——使用者覺得網站難用、容易誤觸。三個指標一起壞掉 = 跳出率飆高 = SEO 排名往下掉 = 廣告投放成本上升（因為 Google Ads 也看品質分數）。

Google 官方目前公告的三大指標通過門檻（2026 年版本，跟 2025 年 3 月 INP 替換 FID 之後沒再變動）：

這裡有一個常被誤解的地方：Google 算的是 第 75 百分位。意思是你的網站要有 75% 的真實使用者訪問都達標，那個指標才算過。所以你用自己手機開一次測一下覺得很快——那只是「中位數使用者」的體驗，後面 25% 用舊手機、用 4G 的使用者可能跳出率高得嚇人。

INP 為什麼是 2026 中小企業網站最大的殺手

2025 年 3 月 12 日是個分水嶺。那天 Google 把 INP 正式替換掉舊的 FID 指標，原本 FID 只量「第一次互動的延遲」，很多網站用幾個技巧就能矇混過關；INP 換上後，量的是「整個 session 裡所有互動的第 98 百分位延遲」——意思是你網站只要有 2% 的互動很慢，整個分數就崩了。

根據 web.dev 2026 年 5 月的監測，全球 43% 的網站仍然卡在 INP > 200ms 的門檻——這是三大指標裡通過率最低的「相對值」（雖然絕對通過率 86.6% 看起來高，但這代表 13.4% 全球網站直接被打到「需要改善」，比 LCP 失敗率還集中）。台灣的情況更嚴重，因為主流網站還是 WordPress + 一堆外掛，外掛載入的第三方 JavaScript 沒人管，每次點擊都要等 main thread 跑完才有反應。

INP 變慢的常見原因有四類：第三方 JavaScript（GA4、Meta Pixel、LINE 客服 widget、各種 chat bot）載入時間太長、前端框架的 hydration 卡住 main thread、CSS-in-JS runtime 在每次 re-render 重新計算樣式、以及最常見的——圖片或字型 lazy load 用錯地方反而拖累互動。

我們的判斷：先別急著重做網站，先把字型 + 圖片 + LCP 圖搞定就能拉 30 分

市面上做 SEO 的廠商最常見的話術，是一聽說你 Core Web Vitals 沒過就直接報「整站重做 60-80 萬」。我們不是說重做沒用——重做是真的最快，但中小企業的營收 ROI 算不過來。多數情境的正解是分三階段：

• 階段一（成本 5-10 萬，2-4 週）：字型 self-host、圖片 WebP/AVIF 轉檔 + lazy load、LCP 圖加 preload。光這三件事能把 LCP 從 4 秒拉到 2 秒以下。
• 階段二（成本 15-25 萬，4-8 週）：第三方 JavaScript 治理、CDN 升級到 Cloudflare 或 Vercel、CSS critical path 提取、首屏 server-render。INP 從 400ms 拉到 150ms。
• 階段三（成本 50-80 萬，3-6 個月）：真的不行了再考慮整站 Next.js / Astro 重寫。這時候應該是業績撐得起、訪問量已經到 10 萬月 PV 以上才划算。

這個三階段框架我們在 網站重構 vs 重做完整決策框架 裡面有更詳細的決策樹——6 個訊號告訴你只要修補、5 個訊號該整個重做，可以拿去跟廠商對話。

4 條優化路徑成本對比表

4 條 Core Web Vitals 2026 優化路徑拆解（含實做技術棧）

路徑 A：字型、圖片、LCP 圖三件事（5-10 萬）

這條路徑的核心觀念是「先處理重量級資源」。一個典型的 WordPress 網站，首屏載入會卡在三件事：Google Fonts 外連、未壓縮的主視覺 JPG、以及 LCP 元素（通常是 H1 旁邊那張大圖）沒有預載。

具體做法：把 Google Fonts 抓下來 self-host 用 woff2 格式 + font-display: swap、所有 banner 圖轉 WebP（或 AVIF，但要做 fallback）、給 LCP 圖加 。多數 WordPress 主題有對應外掛能做（Perfmatters、Autoptimize），但建議找熟手手動處理外掛漏掉的地方。這條路徑的好處是低風險、不動內容、不動模板，2 週可以驗收。

路徑 B：A + CDN + 第三方 JavaScript 治理（15-25 萬）

把網站搬到 Cloudflare 或 Vercel CDN，加上對第三方腳本（GA4、Meta Pixel、LINE 客服）做延遲載入與 web worker 隔離。這條路徑會明顯改善 INP，因為 main thread 不再被一堆 tracking script 卡住。CDN 選型可以參考我們之前寫的 Cloudflare Workers vs Vercel Edge vs AWS Lambda 採購決策。

這條路徑有個風險：第三方腳本延遲載入可能讓行銷部門的轉換追蹤資料變不準——點進來的人還沒被 GA4 認到就跳走了。所以實做前要跟行銷主管對齊容忍度。我們的做法是把「conversion-critical」的腳本（購物車事件、Lead 表單）留在原本載入時機，「analytics-only」的腳本（GA4、熱圖工具）才延遲。

路徑 C：WordPress + Headless CMS（30-50 萬）

這條路徑常被 SEO 廠商推銷——把 WordPress 後台留著當編輯介面，前台用 Next.js 重寫。聽起來很美，但執行落差很大。實際做下來要踩的坑包括：preview 預覽不能即時、外掛生態斷掉、search 功能要重寫、編輯人員學習曲線陡。

我們的建議：除非你的內容團隊大、改版很頻繁（每月超過 30 篇新文章），不然 Headless 不見得划算。中小企業多數的情境，把路徑 B 做完就夠了，剩下的預算拿去做內容比拿去做 Headless 更划算。

路徑 D：整站 Next.js / Astro 重寫（50-80 萬）

這是「核選項」。優點是 Core Web Vitals 可以做到全綠且穩定（LCP < 1s、INP < 100ms、CLS ~ 0），SEO 排名與 Google AI Overview 引用優先序都會明顯往上拉。缺點是時間長、要管 SEO 301 redirect 不能斷、要養前端工程師團隊。Next.js 16 之後支援 Partial Prerendering 把首屏靜態化，是這條路徑的最佳工具。

3 個 ROI 試算情境：什麼時候動手最划算（給採購評估者）

成本攤完了，接下來算回收。我們用三個真實情境做 ROI 試算，讓採購評估者拿著數字去跟老闆要預算。三個情境的營收基礎不同，但結論一致：路徑 A 永遠值得做、路徑 B 看流量、路徑 C/D 看營收規模。

這些 conversion 提升不是憑空亂寫。Vodafone Italy 把 LCP 改善 31% 後銷售提升 8%、購物車轉換提升 11%；Amazon 與 Walmart 內部研究顯示 1 秒延遲讓轉換率掉 7%、100ms 延遲讓銷售掉 1%。Rakuten 改善三大指標後轉換提升 33%、每訪客營收提升 53%。台灣中小企業的提升幅度通常落在這些國際案例的 50-70%，因為基期不同。

自架 vs 找廠商代操：4 個決策節點

Core Web Vitals 優化不一定要外包。但內製有四個前提：團隊有前端工程師、有時間做 6-12 週的迭代、行銷主管能接受優化期間流量波動、老闆有耐心給 3-6 個月觀察排名變化。少一個都建議外包。

廠商怎麼挑？三個紅線：不簽 SLA 不要、不給 PageSpeed before/after 報告不要、不肯交 source code 與 build 流程不要。第一個鎖住廠商有交付責任，第二個讓你能驗收，第三個避免被綁死。SEO 廠商挑選的細節可以參考 Google Search Console 完整教學，把 Search Console 的「核心網頁指標」報告當驗收依據，比聽廠商口頭交付可靠十倍。

常見地雷：為什麼做完 PageSpeed 100 分還是 SEO 沒起色

這三個地雷我們經手的案子裡至少有六成踩過。最諷刺的是地雷三——優化做完當下 PageSpeed 95 分老闆很開心，三個月後行銷部門接了個新 CRM、加了三個 chat widget、跑分掉到 55 分沒人知道，直到 Search Console 跳警報。所以我們的標準做法是把 PageSpeed 監控接到 Slack 或 Email alert，分數掉 5 分以上就主動通知。

如果 SSR 主機真的撐不住流量尖峰，可以參考我們之前寫的 Cloudflare 救援機制完整實戰 用 stale-if-error 把流量 hold 住，避免 LCP 暴衝到 10 秒以上的災難場景。另外想自己跑檢測，PageSpeed Insights 工具使用教學 有完整步驟。

我們自己怎麼做：foreverwebs.com 700+ 篇部落格的 Core Web Vitals 治理

講優化方法不講自己做不做就是嘴砲。我們自己的 foreverwebs.com 站上有 700 多篇部落格文章、加上首頁、服務頁、作品集，目前 Core Web Vitals 真實使用者數據維持在 LCP 1.2 秒、INP 80ms、CLS 0.01——三個全綠。技術棧是 Next.js 14 ISR + Cloudflare CDN + 全站 WebP/AVIF 圖片、字型 self-host + preload、首屏 server-render、第三方 script defer。

這套架構不是一次到位的。第一年我們也跑過 WordPress + WP Rocket，跑分大概 70 分。後來搬 Next.js 重寫，初期 LCP 反而變糟——因為 Cloudflare R2 圖片沒走 CDN、有些 banner 圖直接從 R2 拉。處理掉之後又遇到 Lexical 編輯器在文章頁拖累 hydration，INP 飆到 300ms。一個個修，花了大概 9 個月才把三個指標都壓進綠區。

我們公司自己每天就在跑 20+ 個 AI 流程，其中一個專門監控全站 PageSpeed——每天清晨跑全站 sample 100 個 URL，分數掉 5 分以上就 Slack 通知。這套監控自己長期跑下來，能在第三方腳本悄悄加回來、或圖片 alt 漏設的當下就抓到，不用等 Search Console 三週後才警報。內部 AI 流程的設計細節可以參考我們的 企業內網 AI 助理自架完整指南。

90 天 Core Web Vitals 行動表（中小企業老闆可以直接抄）

把上面所有內容濃縮成 90 天具體行動。前 30 天診斷與快贏、中 30 天結構優化、後 30 天監控落地。每個階段有可驗收的 KPI、有對應預算區間、有需要誰參與。

• Day 1-7：跑全站 PageSpeed Insights + 開 Search Console 核心網頁指標報告，列出最差的 20 個 URL。預算 0。
• Day 8-21：執行路徑 A（字型 + 圖片 + LCP 圖）。驗收 KPI：LCP 4s → 2s 以下、PageSpeed 整站平均 +20 分。預算 5-10 萬。
• Day 22-30：跑第二輪 Field Data，確認真實使用者數據改善。Search Console 報告通過率應從 30% 提升到 60% 以上。
• Day 31-60：執行路徑 B（CDN + JS 治理）。驗收 KPI：INP 400ms → 180ms、跳出率 65% → 50% 以下。預算 15-25 萬。
• Day 61-75：寫自動化監控腳本接 Slack。預算內製或 5 萬外包。
• Day 76-90：跑全站第三輪 audit，自然搜尋流量應已 +30-50%、自然搜尋 conversion 應已 +12-20%。把數據整理成單頁報告給老闆。

這份行動表已經有客戶照抄過——我們不能透露細節，但典型結果是 90 天內把自然搜尋流量從每月 8 千 session 拉到 1.5 萬 session，Lead 從每月 22 個變 41 個，跳出率從 65% 降到 42%。Lead 變多後三個月，業務團隊終於敢把廣告投放預算砍掉一半，把錢換到內容生產上——這個正向循環才是 Core Web Vitals 真正的價值。

如果你也在卡 Core Web Vitals，可以這樣開始

看到這裡，如果你也在想「我的網站到底要不要動」「動的話該找誰」——可以把 PageSpeed Insights 跑出來的截圖丟過來，我們 聽你聊聊現況，一起看看你的情境屬於路徑 A / B / C / D 哪一條、預估投入與回收。這個階段我們陪你想，後面真的要動手再談範圍跟費用。

如果你已經確定要整站重做、想找會做 Next.js / Astro 的客製化團隊，可以直接看我們的 客製化網站開發服務 或 系統開發服務 頁面。