Core Web Vitals 優化實戰指南｜改善 LCP、INP、CLS

網站在辦公室高速網絡看似流暢，不代表手機使用者也有相同體驗。圖片遲遲才出現、點擊後沒有反應，或按鈕突然移位，都可能令客戶放棄瀏覽與查詢。Core Web Vitals 把這些真實體驗轉成可量度指標。LeadsTech 在診斷網站效能時，會把真實使用者數據、頁面商業價值與技術瓶頸一起排序，避免只為追求測速分數而忽略客戶旅程。本文將說明如何判讀數據、找出原因並按商業影響修正。

本文重點精華（TL;DR）

Core Web Vitals 以 LCP、INP、CLS 分別量度載入、互動與視覺穩定。良好門檻是 LCP 不高於 2.5 秒、INP 不高於 200 毫秒、CLS 不高於 0.1，並以真實使用者第 75 百分位判斷。優化要先看 CrUX 或 RUM 的 Field Data，再用 Lighthouse 等 Lab Data 重現問題。企業應按頁面群組與轉換價值排序，而不是只追求單次 100 分。

1. Core Web Vitals 是甚麼？為何企業需要關注？

Core Web Vitals 是 Google 用來量度真實網頁體驗的一組核心指標，涵蓋主要內容出現速度、互動後回應速度，以及頁面是否意外移動。這些指標反映使用者是否能快速看見、操作並信任頁面，而不只是一個技術分數。

Google 建議網站達到良好 Core Web Vitals，因為頁面體驗是搜尋核心排名系統考慮的眾多因素之一。但通過指標並不保證排名上升；內容相關性、品質、連結、搜尋意圖及其他體驗訊號仍然重要。對企業而言，更直接的價值是減少流失、錯按與操作等待。

2. 如何讀懂 LCP、INP、CLS 三項指標？

評估時要看第 75 百分位，即至少 75% 的真實瀏覽體驗達到門檻。流量較多的慢裝置、行動網絡、登入狀態及地區差異，可能令真實結果與內部測試完全不同。

• Largest Contentful Paint（LCP）：量度主要內容元素完成顯示的時間，良好門檻為 2.5 秒或以下。常見元素包括 hero 圖片、大標題或主要內容區塊。
• Interaction to Next Paint（INP）：觀察整個瀏覽期間的互動回應，良好門檻為 200 毫秒或以下。點擊選單、篩選商品或開啟表單後的視覺回應都可能影響 INP。
• Cumulative Layout Shift（CLS）：量度非使用者預期的版面移動，良好門檻為 0.1 或以下。圖片、廣告、字體或延遲插入內容沒有預留空間時，最容易出現偏移。

頁面要通過整體 Core Web Vitals 評估，三項指標都要達到良好範圍。手機與桌面應分開檢查，因為處理能力、網絡、視窗和互動方式不同。

3. Field Data 與 Lab Data 為何會不同？

Field Data 來自真實使用者。Chrome UX Report（CrUX）會匯總符合條件的 Chrome 瀏覽體驗，PageSpeed Insights 和 Search Console 的 Core Web Vitals 報表都會使用這類資料。PageSpeed Insights 一般顯示最近 28 日的滾動數據；Search Console 則把體驗相似的 URL 分成群組，方便找出網站層面的模式。

Lab Data 是在受控裝置與網絡條件下執行的測試，例如 Lighthouse。它適合重現、逐步分析與驗證修正，但不能代表所有真實訪客。網站可能在 Lighthouse 表現良好，Field Data 仍然不合格，原因包括真實裝置較慢、第三方程式在特定狀態才載入，或使用者進行了實驗室測試沒有覆蓋的互動。

正確流程是用 Field Data 找問題、以 Lab Data 診斷，再用 Real User Monitoring（RUM）和後續 Field Data 驗證。只有少量流量的頁面可能沒有 URL 級 CrUX 資料，此時可參考 origin、同類頁面群組和自建 RUM。

4. 如何改善 LCP 載入速度？

先確認真正的 LCP 元素，不要假設一定是 hero 圖。把 LCP 分解為伺服器回應、資源發現延遲、資源下載與元素呈現，才能找對瓶頸。

• 改善伺服器與 CDN 快取，減少 Time to First Byte（TTFB）。
• 讓 LCP 圖片在初始 HTML 中可被發現，避免以 JavaScript 很遲才插入。
• 不要對首屏 LCP 圖片使用 lazy loading；按需要使用 preload 或 fetch priority。
• 提供合適尺寸、響應式來源和高效圖片格式，避免下載遠大於顯示尺寸的檔案。
• 減少阻塞首屏的 CSS、字體與同步 JavaScript，延後非必要第三方程式。
• 在動態網站預先產生或快取高流量頁面，避免每次請求都進行昂貴後端計算。

最常見錯誤是只壓縮圖片，卻沒有處理伺服器慢、資源發現太遲或主要內容被 JavaScript 擋住。每次改動都要回到時間分解驗證。

5. 如何改善 INP 互動回應？

INP 問題通常出現在主執行緒太忙。使用者點擊後，瀏覽器仍在執行長 JavaScript 任務、計算樣式或大量更新 DOM，畫面便無法及時提供回饋。

• 在真實頁面記錄最慢的互動類型、元素、URL、裝置與狀態。
• 把長任務拆成較小工作，讓瀏覽器有機會處理輸入與繪製。
• 減少初始 JavaScript，按頁面與功能拆分程式，只載入當前需要的部分。
• 避免一次更新大量 DOM 或反覆讀寫版面，批次處理 UI 變更。
• 檢查標籤管理、聊天、個人化及分析等第三方程式對主執行緒的影響。
• 在操作開始時立即提供視覺回饋，並把非必要後續工作延遲處理。

INP 不是只量度第一下點擊。頁面使用時間越長，選單、篩選、加入購物車、分頁和表單驗證都可能成為最差互動。因此測試要覆蓋完整任務，而非只載入首頁。

6. 如何改善 CLS 版面穩定？

CLS 的核心是預留空間。圖片與影片要設定 width、height 或 aspect-ratio；廣告、推薦、Cookie 橫幅和動態元件要有穩定容器；不要在使用者正在閱讀時把內容插入現有段落上方。

自訂字體可能因替換造成文字重排，可使用合適 fallback、字體預載及字體度量調整。動畫應優先使用 transform 和 opacity，避免改變 top、left、width 或 height 觸發版面重新計算。測試時要模擬登入、個人化、廣告及錯誤訊息等不同狀態。

7. 假設情境：電商活動頁應如何診斷？

假設某電商品牌活動頁在辦公室測試很快，但手機轉換下降。Search Console 顯示商品頁群組 LCP 與 INP 不合格；PageSpeed Insights 發現 hero 圖由輪播程式很遲才加入，而商品篩選一次執行大量 JavaScript。促銷橫幅在載入後插入頁首，亦導致 CLS。

團隊可把首張 hero 圖直接放入初始 HTML、提供正確尺寸與優先級；把篩選程式拆分並減少不必要 DOM 更新；為促銷欄預留高度。上線時先監察少量流量，使用 RUM 比較 LCP 元素、最慢互動和 CLS 來源，再等待 28 日 Field Data 趨勢逐步反映。

除了三項指標，商業團隊應同步觀察商品瀏覽至加入購物車率、結帳開始率、錯誤率和收入。若效能改善但轉換沒有變化，仍要檢查價格、內容、庫存、表單及行銷流量質素。

8. Core Web Vitals 優化實施流程

優化不應從隨機修改開始，而要由真實數據逐步收窄至可重現原因，再安全發佈並持續監察。

9. 上線與監察檢查清單

• 是否以第 75 百分位而非平均值判斷三項指標？
• 手機和桌面是否分開檢查？
• 是否清楚知道 LCP 元素與最慢互動？
• 圖片、影片、廣告和動態模組是否預留尺寸？
• 第三方程式是否有擁有人、用途和效能預算？
• 主要轉換流程是否在真實裝置完成測試？
• 發佈管道是否包含 Lighthouse 或其他性能回歸檢查？
• RUM 是否記錄頁面模板、裝置、地區及版本？
• 是否同時追蹤轉換、錯誤與營收，而非只看技術分數？

10. 常見問題

11. 結語

Core Web Vitals 優化不是一次性的 PageSpeed 分數工程，而是把真實使用者體驗納入產品、內容、開發和營運決策。企業應先建立 Field Data 基準，按頁面價值找原因，再以安全發佈和持續監察防止回歸。如需進行真實使用者診斷、性能測試及修正規劃，可了解 LeadsTech 的 網站效能測試及優化服務，或透過 Contact Us 與團隊討論。

了解網站效能測試及優化服務聯繫我們

12. 延伸閱讀

• CMS 如何影響 SEO？網站內容管理系統優化指南：了解內容平台、模板與技術 SEO 的關係。
• 網站數據分析與優化：Adobe Analytics＋CDP 應用：把效能數據與客戶行為及轉換連接。
• SEO＋GEO＋AI 搜尋成長策略：提升品牌曝光與商機：延伸至搜尋能見度與網站成長策略。