網站速度健檢：LCP、INP、CLS 怎麼看？先分清實驗室與真實用戶資料

PageSpeed 顯示 55 分，網站就一定很慢嗎？不一定。

速度健檢最常見的誤判，是只看一個 Lighthouse 分數，卻沒分清楚測試環境、真實使用者資料與真正拖慢的元素。

三個 Core Web Vitals 在量什麼

指標	使用者感受	Google 官方 good 門檻
LCP	主要內容多久出現	2.5 秒內
INP	點擊後多久看到回應	低於 200ms
CLS	載入時畫面會不會跳	低於 0.1

門檻以真實使用者第 75 百分位評估。LCP 2.0 秒可以是工作室內部嚴格目標，但不能寫成 Google 官方合格線；官方仍是 2.5 秒。

Lab data 與 Field data 要分開

Lab data：固定條件下找問題

Lighthouse 模擬特定裝置與網路，可重複執行，適合找出阻塞資源、過大圖片與主執行緒工作。缺點是單次測試會受到伺服器冷啟動、網路與測試位置影響。

Field data：真實使用者的結果

PageSpeed Insights 的 CrUX 資料與 Search Console Core Web Vitals 報告來自真實訪客，較接近 Google 評估頁面體驗的方式，但需要足夠流量才能形成資料。

沒有 Field data 不代表通過，也不代表失敗，只代表樣本不足。

LCP 高，先找最大內容是誰

常見 LCP 元素：

首頁 Hero 大圖
輪播第一張圖
首屏大標題與 Web Font
影片封面或嵌入 iframe
伺服器回應太慢造成整頁延後

排查順序：

在 PageSpeed 找出 LCP element。
看 TTFB 是否先天過高。
檢查首屏圖片尺寸、格式與優先載入。
檢查 CSS、字體與第三方資源是否阻塞。
重跑至少三次，看中位數而非最好的一次。

首屏 LCP 圖通常不應 lazy-load；它需要正確尺寸、現代格式與合理的優先載入。

INP 高，問題通常在點下去之後

INP 指的是使用者互動後，瀏覽器多久呈現下一個畫面，不是「頁面看起來載完的時間」。

常見來源：

聊天、追蹤與廣告腳本太多
大型 JavaScript bundle
外掛同時監聽很多事件
點擊後同步執行大量運算
第三方表單或選單初始化過重

先在真正會互動的頁面測：導覽選單、商品篩選、加入購物車與表單，比只測靜態首頁有意義。

CLS 高，是因為空間沒有先保留

常見來源：

圖片與影片沒有寬高或 aspect ratio
字體載入後尺寸差異太大
Cookie banner、廣告或通知突然插入
非同步內容出現在既有內容上方

修法是讓瀏覽器在資源載入前就知道要保留多少空間，不只是壓縮圖片。

一次速度健檢怎麼跑

選首頁、主要服務頁、商品頁與結帳／詢價頁。
手機模式各跑三次 Lighthouse，記錄中位數。
查看 PageSpeed 是否有 Field data。
在 Search Console 看同類 URL 群組。
記錄 LCP element、長任務與版面位移來源。
一次只改一類問題，再用同條件重測。

驗收表至少要保留日期、URL、測試裝置、TTFB、LCP、INP、CLS、修改內容與結果。

常見問題

Q：Performance 100 分才算好嗎？

A: 不需要。分數是診斷摘要，重點是關鍵頁面的真實體驗與三項指標，不要為了滿分刪掉必要功能。

Q：Lighthouse 沒顯示 INP 怎麼辦？

A: INP 需要真實互動資料。Lab 環境可用 Total Blocking Time 等診斷資訊輔助，但不能直接把它當成 INP。

Q：升級主機能解決所有速度問題嗎？

A: 不能。主機主要改善伺服器回應；若 LCP 卡在大圖、字體或第三方腳本，升級主機不會自動修好。

下一步

先測真正帶來詢價或訂單的三個頁面，不要只測首頁。也可使用免費網站健檢，或閱讀主機、CDN、快取該怎麼選。