Core Web Vitals 白話解析：LCP、INP 與 CLS

Core Web Vitals 不是你網站的人格測驗

Core Web Vitals 經常被當成一張神祕的成績單。頁面得到一個紅色數字，有人在 Slack 貼出截圖，然後團隊開始爭論 JavaScript 框架。

這並不特別有幫助。

更好的理解方式其實很簡單：Core Web Vitals 是三項測量，用來判斷一個頁面在真實裝置上，對真實使用者來說是否好用。它們無法涵蓋效能、可及性或品質的每個面向。但它們確實能抓出三種常見的挫折來源：

• 主要內容太久才出現。
• 使用者嘗試操作時，頁面反應很慢。
• 使用者正在閱讀或點按時，版面到處跳動。

這三項就是 Core Web Vitals：LCP、INP 與 CLS。

Google 會將它們作為頁面體驗訊號的一部分，但 SEO 角度並不是最值得在意的理由。更好的理由是：緩慢、跳動、沒有回應的頁面會浪費使用者時間。這類頁面通常也更難轉換、更難支援，並且更容易隨時間劣化。

三項指標各用一句話說明

在進入細節之前，先用白話版本說明：

• LCP，也就是 Largest Contentful Paint，衡量主要可見內容需要多久才載入。
• INP，也就是 Interaction to Next Paint，衡量使用者在整個造訪期間操作頁面時，頁面回應得有多快。
• CLS，也就是 Cumulative Layout Shift，衡量頁面發生多少非預期的位移。

常見門檻如下：

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s 或更快 | 2.5s–4.0s | 超過 4.0s | | INP | 200ms 或更快 | 200ms–500ms | 超過 500ms | | CLS | 0.1 或更低 | 0.1–0.25 | 超過 0.25 |

這些數字通常會以真實使用者造訪的 第 75 百分位數 來評估。這一點很重要。你的目標不是做出一次完美的實驗室測試，而是讓大多數使用者都有良好體驗，包括使用較慢手機與較不穩定網路的人。

如果你正盯著自動化報告，不確定該從哪裡開始，最好把診斷和恐慌分開。我們另有一份關於如何閱讀 Lighthouse 報告而不恐慌的指南，會更詳細說明那個流程。

LCP：頁面何時感覺已載入？

Largest Contentful Paint 衡量視窗中最大可見內容元素的繪製時間。實務上，這通常是：

• hero image，
• 大標題，
• 精選文章圖片，
• 產品圖片，
• 一大段文字。

LCP 問的不是每個 script、追蹤像素和首屏以下圖片何時全部載入完成。它問的是：使用者來看這個頁面時最主要想看的東西，何時變得可見？

這讓 LCP 比老派的「頁面載入時間」更接近人的感受。頁面在技術上可能很晚才完成載入，但如果主要內容很快出現，仍然會感覺很快。反過來也一樣：頁面可能已觸發 load event，但 hero 區域仍然空白、模糊，或被 render delay 擋住。

LCP 不佳的常見原因

多數糟糕的 LCP 問題來自幾個可預期的地方：

1. 伺服器回應緩慢

如果 HTML 文件很晚才抵達，其他所有事情都會跟著變晚。

1. 阻擋渲染的 CSS 或 JavaScript

瀏覽器已經有內容，但還不能把它畫出來。

1. 未最佳化的 hero images

最大元素太大、格式不對、沒有被優先處理，或誤用了 lazy-load。

1. Web fonts 延遲文字渲染

大標題可能是 LCP 元素，而字型載入可能延遲它，或讓它在視覺上產生變化。

1. Client-side rendering 延遲

如果頁面必須先載入大型 JavaScript bundle 才能顯示有意義的內容，LCP 就會受影響。

如何改善 LCP

從實際的 LCP 元素開始。不要在還不知道瀏覽器測量什麼之前，就隨機最佳化資產。

實用修正包括：

• 快速提供 HTML：在適當位置使用快取、減少後端工作、避免緩慢的重新導向。
• 最佳化 LCP 圖片：使用正確尺寸、壓縮與格式。
• 不要對首屏 hero image 使用 lazy-load。
• 當主要圖片確實是優先項目時，謹慎使用 fetchpriority="high"。
• 只有在能有意義地降低 render delay 時，才 inline critical CSS。
• 減少第一次有意義渲染之前所需的 JavaScript。
• 使用 font-display: swap 或另一種有意識的字型策略。

圖片和字型經常是元凶。對圖片來說，取捨不只是「檔案小就好」。格式選擇、編碼成本與瀏覽器支援都很重要，因此我們保留了一份實用決策樹，說明 AVIF 何時勝過 WebP、何時不會。對文字量大的頁面而言，web fonts 仍然是最容易取得的效能改善之一，因為許多網站送出的字型檔比實際使用的更多。

INP：頁面被觸碰時有回應嗎？

Interaction to Next Paint 衡量回應性。更具體地說，它觀察的是使用者互動與瀏覽器處理該互動後下一次視覺更新之間的延遲。

互動包括像是：

• 點擊按鈕，
• 點按選單，
• 選取核取方塊，
• 在表單欄位輸入，
• 開啟 accordion。

INP 在 2024 年取代 First Input Delay，成為 Core Web Vital。這是很好的改變。First Input Delay 只看第一次互動。INP 更廣：它會考量整個頁面造訪期間的互動，並將高延遲互動回報為頁面的回應性分數。

白話說：INP 會抓出那些看起來已載入、但感覺卡住的頁面。

你大概用過這樣的頁面。它看起來已經準備好了。你點按選單。半秒鐘什麼都沒發生。你又點一次。然後兩件事同時發生。這就是 INP 問題。

INP 不佳的常見原因

INP 通常是 main-thread 問題。瀏覽器想要回應，但 JavaScript、渲染工作或版面計算擋在路上。

典型原因包括：

• 大型 JavaScript bundles，
• 昂貴的 event handlers，
• client-rendered apps 的 hydration 工作，
• 與 main thread 競爭的第三方 scripts，
• 頁面載入後的長時間執行 tasks，
• 由小互動觸發的複雜 DOM 更新，
• layout thrashing，也就是程式碼反覆讀取和寫入版面值。

行銷標籤、analytics、聊天小工具和同意橫幅都可能有所影響。這不表示「全部移除」。它表示頁面上的每個 script 都有成本，而互動延遲通常就是這個成本變得可見的地方。

如何改善 INP

改善 INP 與其說是靠某個神奇屬性，不如說是減少 main-thread 競爭。

有用的做法包括：

• 將長時間 JavaScript tasks 拆成較小區塊。
• 將非必要工作延後到頁面可用之後。
• 移除未使用的 JavaScript，而不只是壓縮它。
• 讓 event handlers 保持小而可預期。
• 避免為了微小狀態變更而重新渲染介面的大範圍區塊。
• 在可行時，使用 CSS 處理簡單的視覺狀態。
• 稽核第三方 scripts，並只在需要的地方載入它們。

也要看看互動設計。即使後續工作需要更久，一個能立即給出視覺回饋的按鈕也會感覺更有回應。這不能取代效能，但它是良好介面工程的一部分。我們的 accessible web buttons 檢查清單也與此重疊：清楚狀態、正確語意與可預期行為，同時幫助使用者與瀏覽器。

CLS：頁面會留在使用者預期的位置嗎？

Cumulative Layout Shift 衡量可見元素的非預期移動。如果使用者開始閱讀某段文字，而上方的廣告、圖片或橫幅載入後把文字往下推，這就會計入 CLS。

CLS 不是以秒數衡量。它是一個根據內容移動量與移動距離計算出的分數。越低越好。

關鍵字是 非預期。由使用者操作造成的版面變化，通常不會以相同方式計算。如果有人點按「顯示更多」後內容展開，那是預期中的事。如果電子報橫幅在三秒後出現在頂端，並把所有內容往下推，那就不是。

CLS 不佳的常見原因

CLS 失敗通常很平凡：

• 圖片缺少 width 和 height attributes，
• 廣告或 embeds 沒有預留空間，
• cookie banners 被插入到內容上方，
• web fonts 以不同 metrics 交換載入，
• 載入較晚的促銷列，
• 在頁面頂部附近動態注入內容。

修正方式通常是在內容抵達前先預留空間。瀏覽器應該越早知道頁面的形狀越好。

如何改善 CLS

從可見的位移開始。觀看錄影或使用瀏覽器工具，找出哪些元素正在移動。

然後套用那些無聊但有效的修正：

• 為圖片加入明確的 width 和 height attributes。
• 為 responsive media containers 使用 CSS aspect-ratio。
• 為廣告、embeds 和 iframes 預留固定或最小空間。
• 避免在載入後把 banners 注入到既有內容上方。
• 選擇 metrics 與最終字型相近的 font fallbacks。
• 避免會改變 top、left、width 或 height 等版面屬性的動畫；優先使用 transforms。

CLS 是少數紀律勝過聰明技巧的效能指標之一。如果頁面有穩定的盒子，分數通常就會不錯。

Field data 和 lab data 都有用，但回答的是不同問題

常見的困惑來源是，不同工具會顯示不同數字。這很正常。

Field data 來自真實使用者。它反映實際裝置、網路、地點與瀏覽器條件。Google 的 Chrome User Experience Report 就是 field data 的例子。

Lab data 來自受控測試環境。Lighthouse 是大家熟悉的例子。它可重複且有助於除錯，但它不等同於使用者的真實體驗。

使用 field data 來判斷使用者是否真的遇到問題。使用 lab data 來重現並除錯那個問題。

也請記得，Core Web Vitals 通常是依 URL 或 URL 群組評估，而不是你品牌的一個抽象單一屬性。你的首頁、部落格文章、定價頁與結帳流程，可能有非常不同的瓶頸。

合理的工作順序

如果三項指標都很差，很容易想從所有地方同時開始。請克制。

實用順序如下：

1. 先修明顯的 CLS

缺少圖片尺寸與不穩定的 banners 通常是快速改善點。

1. 改善重要 templates 的 LCP

專注在重要頁面：產品頁、landing pages、文章、註冊流程。

1. 用真實互動調查 INP

點擊使用者實際會點的東西。選單、篩選器、表單和結帳控制項，通常比初始載入 trace 揭露更多問題。

1. 稽核第三方 scripts

保留能證明成本合理的項目。移除或延後那些不值得的項目。

1. 設定 performance budget

沒有 budget，效能改善會衰退。新的 scripts、圖片與設計元件會悄悄抵消已完成的工作。

重點是：不要為了徽章而最佳化。要為使用者旅程而最佳化。低流量頁面上的些微分數改善，可能不如一個稍不完美但快得多的結帳互動重要。

<!-- tool-cta:start -->

💡 試試這個： 由於 LCP 通常是圖片問題，先用 Image Compressor 壓縮你的首屏主視覺資源，作為一個簡單的初步優化。

<!-- tool-cta:end -->

Core Web Vitals 沒告訴你的事

Core Web Vitals 很有用，但並不完整。

它們不會告訴你內容是否好。它們不會告訴你導覽是否合理。它們不保證可及性。它們不衡量隱私、安全、信任、可讀性，或頁面是否回答了使用者的問題。

它們也無法取代判斷。頁面可以通過 Core Web Vitals，卻仍然令人不舒服。一個複雜應用程式也可能未達門檻，但仍然是在其限制下負責任地工程化。

把 LCP、INP 與 CLS 當成煙霧警報器。警報響起時，就去調查。安靜時，也要持續維護這棟建築。