Core Web Vitals 怎麼修？LCP INP CLS 實戰

我用手機打開那家電商的首頁，開始數秒。

一、二、三、四。主視覺才出來。

Search Console 的核心網頁指標報表全紅。LCP 4.8 秒。INP 420 毫秒。CLS 0.31。跳出率 71%。

客戶問我要不要換主機。我說先不要。

LCP 修圖片，INP 修腳本，CLS 修版位。三件事的順序不能換。多數網站的瓶頸在圖片與第三方腳本，不在主機。

第一天：先量，不要先改

打開 PageSpeed Insights 跑行動版，記下三個數字。

打開 Chrome DevTools 的 Network 面板，把網速調成 4G，重新載入，看瀑布圖。

第一眼看到的是一張 3.2MB 的 PNG。首頁主視覺。

TTFB 是 340 毫秒。主機沒有問題。

第二天到第四天：修 LCP

LCP 量的是最大那塊內容多久畫出來。這個站的最大內容就是那張 3.2MB 的圖。

把 PNG 轉成 WebP，寬度限制在 1600 像素。檔案從 3.2MB 掉到 180KB。
在圖片標籤加 fetchpriority 等於 high，讓瀏覽器先抓它。
把首屏以下的圖片全部加 loading 等於 lazy。首屏的圖片不要加，加了會變慢。
把字型檔案改成 woff2，並加上 font-display 等於 swap。
把主視覺的圖片網址寫成 preload。

第四天再量。LCP 從 4.8 秒掉到 2.1 秒。

第五天到第八天：修 INP

INP 量的是使用者點下去之後，畫面多久才有反應。

這個站載入了十一個第三方腳本。聊天外掛、兩套熱區工具、三個廣告像素、一個問卷彈窗、一個評論外掛。

列出所有第三方腳本，逐一問一句話：上個月有人看過它的報表嗎。
沒有人看的四個，直接移除。
聊天外掛改成使用者捲動到 30% 之後才載入。
廣告像素統一搬進 Google 代碼管理工具，用觸發條件延後。
把主題附帶的滑動特效關掉。這一項省下 180 毫秒。

第八天再量。INP 從 420 毫秒掉到 140 毫秒。

第九天到第十天：修 CLS

CLS 量的是版面跳動。使用者要按按鈕，畫面往下彈，手指按到別的地方。

原因有三個。圖片沒寫寬高。廣告版位沒有預留高度。字型換載的時候行高改變。

所有 img 標籤補上 width 與 height 屬性。
廣告與嵌入區塊用 CSS 寫死最小高度。
把後備字型的 size-adjust 調到跟主字型接近。
公告列改成固定高度，不要用動畫展開。

第十天再量。CLS 從 0.31 掉到 0.04。

兩週後的對照

指標	修復前	修復後	門檻
LCP	4.8 秒	1.9 秒	2.5 秒以內
INP	420 毫秒	140 毫秒	200 毫秒以內
CLS	0.31	0.04	0.1 以內
行動版分數	34	88	75 以上
跳出率	71%	43%	越低越好
首頁到加入購物車轉換率	1.6%	2.3%	越高越好

電商網站 Core Web Vitals 修復前後對照。

客戶最後沒有換主機。省下的月費是四千二百元。

三個月後回頭看

速度會壞回去。新的行銷活動會加新的像素，新的頁面會塞新的大圖。

我們的做法是每月一號跑一次 PageSpeed Insights，把三個數字填進同一張表。

任何一項越線就開工單。這件事不能等到 Search Console 寄信才處理，那時候已經壞了二十八天。

兩週修完之後，第二個月做的三件事

第一件是把圖片全部換成新一代格式。四百三十七張圖，用外掛批次轉檔，總容量從一百八十六 MB 降到六十二 MB。

第二件是把第三方腳本重新排序。追蹤碼、客服視窗、社群外掛，三種腳本全部改成延後載入。首屏渲染時間再降零點四秒。

第三件是把字型檔案自架。原本從外部服務載入四款字型，改成自架兩款，減少兩次網域查詢。

三個常見的誤修

第一個誤修是把所有圖片都設成延後載入，包括第一屏的主視覺。主視覺延後載入會讓最大內容繪製變慢，數字反而更差。第一屏的圖要優先載入。

第二個誤修是壓縮過頭。品質壓到五十以下，產品照片的顏色會偏。電商網站因此退貨率上升。品質留在七十五到八十之間。

第三個誤修是把腳本全部延後，包括同意管理平台。同意視窗晚出現，版面會跳動，累積版面配置位移的分數變差。

三個月後那些數字停在哪裡

最大內容繪製從三點八秒降到一點六秒，之後三個月維持在一點五到一點八之間。

與下一次繪製的互動從三百二十毫秒降到一百四十毫秒。累積版面配置位移從零點二七降到零點零三。

跳出率從百分之六十一降到百分之四十七。手機的表單完成率從百分之一點九升到百分之三點三。

營收在同一季增加百分之十八。這個數字裡有多少來自速度，我們沒有辦法完全切開。可以確定的是，三個月裡沒有做其他改動。

量測要用哪一份資料

實驗室工具跑出來的分數是模擬，實際使用者資料才是真的。兩者差距大的時候，聽實際使用者的。

搜尋後台的網站體驗核心指標報表用的是二十八天滾動資料。今天修好，二十八天後才會完全反映。中間的曲線會慢慢往下走，不要每天看。

手機和電腦要分開看。多數網站的問題都在手機，電腦的數字漂亮會騙人。

這次修補的人力與費用

前端工程師八個工作天，設計師兩個工作天，我自己四個工作天做量測與驗收。

外部費用只有圖片轉檔外掛的年費與一台測試主機，合計新台幣一萬兩千元。

人力成本約新台幣十六萬。第三個月的營收增加超過這個數字。

修好之後要防止倒退的三個規則

第一條規則是新圖片上傳前先壓縮，寬度超過一千六百像素的一律縮小。

第二條是新增第三方腳本要先問一句，這個工具帶來的價值是否大於零點三秒。答不出來就不要裝。

第三條是每月一號跑一次量測，數字寫進同一張表。連續兩個月退步就開會。

三條規則寫在網站維護手冊的第一頁。半年後我們回頭看，數字沒有倒退。

先量真實使用者資料，不要只看實驗室分數

工具給的分數是模擬環境跑出來的。真正算進評估的是真實使用者的資料。

Search Console 的網站使用體驗報表看的是過去二十八天的實際訪客。

兩邊差距大的時候，以真實資料為準。我們遇過分數 94 分、真實資料不合格的網站，原因是三成訪客用的是舊款手機。

三個指標各自的第一個嫌疑犯

指標	合格線	第一個要查的東西
LCP	2.5 秒以內	首屏最大的那張圖，看檔案大小與格式
INP	200 毫秒以內	第三方腳本，尤其是聊天外掛與熱區工具
CLS	0.1 以內	沒有寫寬高的圖片與後載入的廣告版位

先查這三個，八成的問題在這裡。

圖片處理的四個動作

轉成 WebP 或 AVIF，同樣畫質檔案小六成以上。
首屏那一張加上 fetchpriority 高優先，其餘的延後載入。
每一張圖標上寬高屬性，讓瀏覽器先留位置。
首屏圖不要放在輪播裡。輪播套件要等 JavaScript 才動得了。

一個客戶只做這四件事，LCP 從 4.6 秒降到 1.9 秒，沒有換主機。

第三方腳本的清點方法

打開開發者工具的網路面板，依網域排序。把不是自家網域的請求列成一張表。

每一行問一個問題：這支腳本是誰要用的，多久看一次數據。

我們替客戶清點過十一次，平均砍掉四支。最常砍掉的是停用很久的熱區工具與換掉的客服外掛。

砍掉之前先問，不要直接刪。刪掉行銷部在用的追蹤碼，會有另一場會議等著。

修完之後要等多久

真實使用者資料是二十八天的滾動平均。今天修好，數字要等三到四週才會全部反映。

不要在第三天看到沒動就再改一次。改兩次以後就分不清是哪一次有效。

記下修正日期，第二十八天再看。這是這件事最需要的一種耐心。

延伸閱讀：SEO / GEO / AEO 系列

這一系列共十篇，從技術地基寫到內容維運。全部收在新知。

速度是轉換率的地板。你想知道自己的網站現在卡在哪一項，可以從下面的入口開始。

常見問題

Core Web Vitals 真的會影響排名嗎？

會，但權重不大。它的價值在轉換率。同樣的流量，載入快一秒的頁面成交數就是比較多。

分數要跑到 100 分嗎？

不用。行動版 75 分以上、三項指標都在門檻內就夠。從 90 分推到 100 分的工，可以拿去寫兩篇文章。

實驗室數據跟實際數據哪個準？

以 Search Console 的實際使用者數據為準。PageSpeed Insights 的實驗室分數只是診斷工具。

換主機有用嗎？

TTFB 超過 800 毫秒才需要考慮換主機。多數網站的問題在圖片與第三方腳本，不在主機。

網站速度工具分數高就合格了嗎？

不一定。工具分數是模擬環境，真正算的是真實使用者資料。我們遇過分數 94 分但真實資料不合格的網站，原因是三成訪客用的是舊款手機。

修好之後多久看得到數字變化？

三到四週。真實使用者資料是二十八天的滾動平均。記下修正日期，第二十八天再看，不要在第三天又改一次。

關於作者與審稿

冠誠數位行銷（GuanCheng Martech）的顧問團隊撰寫這篇文章。團隊累積 295 個專案，服務 308 家客戶，操作範圍包含 SEO 自然排名、AEO 答案引擎、GEO 與 LLMO 佈局、Google 與 Meta 廣告投放、電商維運與數據歸因分析。

文章裡的數字來自冠誠數位行銷實際經手的客戶帳戶與後台報表，客戶名稱與可識別資訊都已經移除。內容由負責該領域的冠誠顧問審稿後發佈，最後更新日期為 2026 年 8 月 10 日。讀完有問題，可以到冠誠數位行銷官方網站的預約諮詢頁面留下聯絡方式，我們會用你提供的時段回電。