Core Web Vitals 優化：網站速度分數怎麼救
發佈 2026-11-05 · 更新 2026-11-04 · 閱讀約 6 分鐘 · AI 工作術（法芮可有限公司）
Core Web Vitals 優化白話教學：LCP、CLS、INP 三個指標分別在量什麼、及格線多少，PageSpeed 分數和 Google 實際採用的資料差在哪。另外整理每個指標最常見的病因與修法，以及修的優先順序，讀完就知道網站速度該從哪裡下手。
網站速度分數很差，先別急著換主機。Core Web Vitals 只看三件事：首屏主要內容多快出現（LCP）、版面會不會亂跳（CLS）、點下去多快有反應（INP）。三個指標的病因各不相同，修法也不一樣，找對原因的話，通常改幾個地方就能從紅燈回到綠燈。
這篇用白話講清楚三個指標，附上 Google 的及格線、該看哪個報表，再整理每個指標最常見的病因與修法。最後列出哪些事值得先做，哪些我們不建議花時間。
先講結論：以 Google Search Console 的真實使用者資料為準，不要追 PageSpeed 的 100 分。先修手機版、先修共用模板，LCP 通常最好救，效益也最大。
LCP、CLS、INP 是什麼？及格線一張表看懂
Core Web Vitals 是 Google 用來衡量「使用者實際體驗」的三個指標，2024 年 3 月起由 INP 正式取代原本的 FID。白話解釋如下：
| 指標 | 白話意思 | 良好 | 需要改善 | 不佳 |
|---|---|---|---|---|
| LCP（最大內容繪製） | 首屏最大的那塊內容（通常是主圖或大標題）多久出現 | 2.5 秒內 | 2.5–4 秒 | 超過 4 秒 |
| CLS（累計版面配置位移） | 載入過程中版面亂跳的程度 | 0.1 以下 | 0.1–0.25 | 超過 0.25 |
| INP（與下一次繪製的互動） | 點按鈕、打字之後，畫面多久有反應 | 200 毫秒內 | 200–500 毫秒 | 超過 500 毫秒 |
有兩個細節很多人搞錯：
- Google 看的是第 75 百分位：不是平均值，而是要 75% 的造訪都達標才算通過。少數網速很慢的使用者也會把你拉下來。
- PageSpeed Insights 那個 0–100 分是實驗室分數：那是 Lighthouse 用模擬的手機和網路跑一次的結果，每次跑都會有落差。Google 實際採用的是頁面上方「真實使用者體驗」那一區，資料來自 Chrome 使用者回報（CrUX），以過去 28 天滾動計算。
所以正確的做法是：先用 Search Console 的「網站使用體驗核心指標」報表找出哪一群網址不及格，再用 PageSpeed Insights 或 Chrome DevTools 找原因。Lighthouse 預設的載入測試不會真的去點擊，所以量不到 INP，只能用「總封鎖時間（TBT）」間接推估。如果你還沒養成固定看 Search Console 的習慣，可以參考 SEO AI 工具完整工作流，把它排進成效追蹤。
LCP 太慢：首屏主圖為什麼出不來
LCP 可以拆成四段：伺服器回應（TTFB）、瀏覽器發現資源之前的延遲、資源下載時間、下載完到畫出來的延遲。PageSpeed Insights 的診斷會告訴你 LCP 元素是哪一個，先確認它是圖片還是文字，再看卡在哪一段。最常見的病因有四個：
- 主圖被設成延遲載入：很多佈景主題或外掛會在所有圖片加上
loading="lazy"，連首屏主圖也不例外。首屏那張圖絕對不要設 lazy，反而要加fetchpriority="high"，讓瀏覽器優先下載。 - 圖片太大：手機只需要 800px 寬的圖，卻下載了 3000px 的原圖。改用 WebP 或 AVIF，搭配
srcset依螢幕大小給不同尺寸，檔案常常能少一半以上。 - 主圖藏在 CSS 背景或 JavaScript 裡：瀏覽器要先下載並解析 CSS、JS，才知道要抓這張圖，一開始就慢了。改用一般的
<img>標籤，或用<link rel="preload">預先載入。 - 伺服器回應慢：TTFB 動不動就超過 1 秒的話，後面怎麼優化都救不回來。檢查頁面快取有沒有開、有沒有上 CDN、資料庫查詢是否太重。
另外，阻擋渲染的 CSS 與 JS 也會拖慢 LCP。非必要的 JS 加上 defer，字型設定 font-display: swap，避免文字要等字型下載完才出現。
我們自己的 AI 自動剪片 產品頁就踩過這個坑：首屏放了示範影片，瀏覽器要等影片資料才畫得出首屏，手機版 LCP 一度掉到紅燈區。後來改成先放一張壓縮過的封面圖（poster），影片等使用者點擊或捲到才載入，LCP 很快就回到綠燈。首屏要放影片的話，LCP 元素一定要是那張封面圖，不能是影片本身。
CLS 跳動：版面為什麼會亂跑
你正要點「加入購物車」，上方突然冒出一條橫幅，結果點到別的東西，這就是 CLS 在量的事。使用者操作後 0.5 秒內的版面變動不計分，所以「點了展開選單」不會被扣分，會扣分的是使用者沒有動作、畫面卻自己跳。常見的病因和修法：
| 病因 | 修法 |
|---|---|
| 圖片、影片沒有寫寬高 | 在 <img> 加上 width 和 height 屬性，或用 CSS aspect-ratio 先佔好位置 |
| 廣告、嵌入內容載入後把版面撐開 | 廣告欄位先設好 min-height，預留最常見的尺寸 |
| Cookie 同意列、促銷橫幅從上方插入 | 改成固定定位的浮動層，蓋在畫面上，不要把內文往下推 |
| 網頁字型載入後，字的寬高跟著改變 | 預先載入關鍵字型，或用 size-adjust 讓備用字型的尺寸接近 |
| 動畫用 top、left 移動元素 | 改用 transform，不會造成版面位移 |
中文網站要特別注意字型。中文字型檔動輒好幾 MB，如果用了自訂中文字型又沒有子集化，換字的那一下整段文字的行高都會變，CLS 很容易爆掉。內文不建議用自訂中文網頁字型，標題真的要用的話，只載入有用到的字。
INP 卡頓：點了沒反應怎麼辦
INP 量的是使用者點擊、觸控、按鍵之後，到畫面真的更新所花的時間，取的是整次造訪中最慢的那幾次互動。病因幾乎都是同一個：瀏覽器的主執行緒被 JavaScript 佔住，你點下去的時候它正在忙別的事。
- 第三方腳本太多：追蹤碼、熱點圖、客服聊天、廣告像素，每個都在搶主執行緒。打開 Google Tag Manager 清一次，半年沒人看的工具直接移除，其他的延後到頁面載入完成再跑。
- 長任務沒有拆開：執行超過 50 毫秒的 JavaScript 任務就算「長任務」。把大段運算拆小，中間把主執行緒讓出來（例如用
setTimeout，瀏覽器支援的話用scheduler.yield()），使用者的點擊才能先被處理。 - 點擊後一次做太多事：按鈕按下去先立刻給視覺回饋（按鈕變色、顯示讀取中），再去跑重的邏輯或呼叫 API，不要讓畫面卡住。
- DOM 太大：一頁同時渲染上千筆商品或留言，每次更新都很吃力。改用分頁，或在無限捲動時搭配虛擬清單。
- 前端框架的水合（hydration）太重：React、Vue 這類網站第一次載入時，要先替整頁接上互動功能，這段期間點擊會卡。可以的話用伺服器渲染、部分水合，或延後載入非首屏元件。
我們營運 AI 工具箱 的經驗是，INP 變差幾乎都不是自己的程式碼造成的，而是一個個加上去的第三方腳本。每加一個行銷工具都覺得「只是一行程式碼」，累積到五、六個，手機上點選單就開始頓。現在我們的規則是：新增任何第三方腳本之前，先在 Chrome DevTools 的 Performance 面板錄一次，看它佔用多少主執行緒時間，再決定要不要裝。
修的順序：哪些先做，哪些不建議
時間有限的話，照這個順序修：
- 先看 Search Console 哪一群網址不及格：報表會把相似的網址分成一群，問題通常出在某個模板（商品頁、文章頁），修好模板就能一次救回幾百頁。
- 先修手機：手機的 CPU 和網路都比桌機差，紅燈幾乎都出在手機。
- 先修 LCP：病因明確、改動小、見效快。其次是 CLS，INP 牽涉到程式架構，通常最花時間。
- 改完先用實驗室分數確認方向，再等真實資料更新：CrUX 以 28 天滾動計算，改完要等幾週才看得到完整成效。
我們不建議做的事：
- 追求 Lighthouse 100 分：從 85 分拉到 100 分的成本非常高，對排名和轉換幾乎沒有差別。真實資料及格後，時間拿去做內容比較划算。
- 同時裝好幾個加速外掛：快取、壓縮、延遲載入的功能會互相打架，最常見的結果是主圖被設成 lazy，或版面直接壞掉。
- 以為速度能救排名：Core Web Vitals 是排名訊號之一，但 Google 明確表示內容相關性與品質更重要。速度的作用是「不被扣分」，真正拉高排名的還是內容的可信度，這部分可以看 E-E-A-T 白話解讀。
常見問題
Q：Core Web Vitals 會直接影響 Google 排名嗎？
會，但權重不高。Google 把它列為頁面體驗訊號之一，多半是在內容品質相近時才會拉開差距。影響更直接的是使用者行為：頁面慢、版面會跳，跳出率和轉換率會最先反映出來。
Q：PageSpeed Insights 分數 90 分以上就代表通過了嗎？
不一定。那個分數是實驗室模擬的結果，Google 判定看的是上方「真實使用者體驗」區塊的 LCP、CLS、INP。實驗室分數高、真實資料卻不及格的狀況很常見，特別是 INP，因為實驗室測試量不到。
Q：修好之後要多久 Search Console 才會變綠燈？
真實資料以 28 天滾動計算，所以至少要等幾週。你可以在報表上按「驗證修正」，Google 會在大約 28 天的觀察期後回報結果。這段期間別一直改東改西，不然很難判斷是哪個修改有效。
Q：網站流量太小，看不到真實使用者資料怎麼辦？
CrUX 要累積足夠的造訪量才會產生資料，小網站常常只看到「資料不足」。這時就用 PageSpeed 實驗室數據和 DevTools 自己測，先修掉 LCP、CLS 的明顯問題，INP 則拿手機實機點點看有沒有明顯延遲。
Q：AI 能幫忙優化 Core Web Vitals 嗎？
可以當助手。把 PageSpeed 的診斷結果或 Performance 錄製的摘要貼給 AI，請它解釋原因、提出修改建議或寫程式碼片段。但改完一定要重新量測，AI 不知道你的網站實際載入了哪些第三方腳本，它給的建議常常要依實際情況調整。