LCP 優化完整指南：從診斷到修復的實戰流程

LCP 分數超過 2.5 秒，通常第一個反應是去壓縮圖片。壓完之後 PSI 分數動了一點點，但 GSC 的 Core Web Vitals 報告還是一片紅。問題出在哪？因為圖片下載時間從來就不是大多數網站的主要瓶頸。這篇文章從 LCP 的四個子部分切入，帶你找出真正的卡點，然後針對性地修復。

LCP 是什麼？2.5 秒背後的測量邏輯

LCP（Largest Contentful Paint，最大內容繪製）測量的是頁面上「最大的可見內容元素」完成渲染所需的時間，從用戶導覽開始計算。Google 的評分標準是：2.5 秒以內為良好、2.5 到 4 秒需要改善、超過 4 秒為不良。

這個指標和 FCP（首次內容繪製）不同。FCP 是第一個任何元素出現的時間，但那個元素可能只是一個小 logo 或單行文字。LCP 追蹤的是用戶真正關心的主要內容，例如新聞文章的頭圖、電商產品的主圖、或是 hero section 的標題文字塊。從用戶感知的角度來看，LCP 比 FCP 更能反映「這個頁面到底載入完了沒」的感受。

Google 在評估 LCP 時使用的是 CrUX（Chrome User Experience Report）中的真實用戶資料，取第 75 個百分位的值。這代表你的網站在過去 28 天內，75% 的用戶訪問中，LCP 都要在 2.5 秒以內，才算通過。

哪個元素會成為你的 LCP 元素？

找出 LCP 元素是診斷的第一步，因為不同元素類型對應不同的優化策略。LCP 元素必須是頁面載入時在 viewport 內可見的，Google 認定有四種主要類型：

• <img> 元素：最常見，尤其是頁面頂部的 hero image 或產品主圖
• <video> 的 poster 圖片：影片封面圖也算，不是影片本身
• CSS background-image：用 background-image: url() 載入的大圖
• 文字塊：如果頁面沒有大圖，大段落文字或大標題可能成為 LCP 元素

用 Chrome DevTools 確認你的 LCP 元素：打開 DevTools → Performance 面板 → 錄製頁面載入 → 在 Timings 區段找 LCP 標記 → 點擊後在下方 Summary 就會顯示具體的 DOM 元素。PSI 報告的診斷區段也會直接標出 LCP 元素。

怎麼找出 LCP 問題所在：診斷三步驟

確認 LCP 元素之後，下一步不是馬上去壓縮圖片，而是看時間到底花在哪裡。Chrome DevTools Performance Insights 面板（或 Performance 面板）會顯示 LCP 的子部分拆解，這是選擇修復方向最重要的資訊。

步驟一：打開 Chrome DevTools → 切到 Performance 面板（或 Performance Insights，Chrome 115 以上支援）→ 點擊「Record page load」或按 Ctrl+Shift+E → 頁面載入完成後停止錄製

步驟二：找 LCP 標記 → 在 Timings 列找到 LCP 紅色垂直線 → 點擊它 → 在下方 Summary 會顯示 LCP 元素和四個子部分的時間分配（Earliest 到 Actual LCP）

步驟三：判斷主要卡點 → 哪個子部分最長，就是你的優先修復目標：

• TTFB 最長 → 主機速度、CDN 問題
• Resource Load Delay 最長 → LCP 圖片被晚發現，preload 或 fetchpriority
• Resource Load Duration 最長 → 圖片真的太大，壓縮或換格式
• Render Delay 最長 → JavaScript 或 CSS 阻擋了渲染

LCP 四個子部分拆解：你的時間真正花在哪裡？

Chrome 工程團隊從 CrUX 真實用戶資料分析發現，對於 LCP 「不良」的頁面，TTFB 中位數約 2.27 秒、資源加載延遲約 1.29 秒，而圖片實際下載時間只有約 350 毫秒。這個數字讓很多人感到意外：圖片壓縮所針對的「resource load duration」，根本不是主要瓶頸。

四個子部分的定義和典型問題如下：

這個分析的實際意義是：如果你的 LCP 問題主要在 TTFB，那麼再怎麼壓縮圖片都沒有明顯改善。要先解決 TTFB，resource load delay 幾乎一定會跟著受益。

縮短 TTFB：LCP 優化的第一優先

TTFB 超過 800ms 通常是 LCP 超標的根本原因。從子部分數據來看，TTFB 是四個子部分中最容易拉長 LCP 的一個，且它的改善會連帶改善 resource load delay（因為 HTML 越晚到，裡面的資源就越晚被發現）。

縮短 TTFB 的具體方向：

• 使用 CDN：把靜態資源和可快取的 HTML 放到距離用戶近的 CDN 節點。對台灣網站來說，國內主機加 Cloudflare 或 BunnyCDN 通常可以把 TTFB 從 800ms 壓到 200ms 以下。
• 啟用 HTTP 快取：設定正確的 Cache-Control header，讓重複訪問的用戶直接從瀏覽器快取載入 HTML 資源。
• 升級主機方案：共享主機在尖峰時段的 TTFB 波動很大，換到 VPS 或 managed hosting 通常有明顯改善。
• 啟用 HTTP/2 或 HTTP/3：多路複用（multiplexing）可以減少多個資源請求的排隊延遲。
• 檢查後端處理時間：如果是動態頁面（WordPress、動態生成），伺服器端的查詢和渲染時間也算在 TTFB 內。啟用全頁快取（WP Super Cache、WP Rocket）可以把動態頁面變成靜態輸出。

之前碰到一個 B2B 客戶，TTFB 有 2.1 秒，主因是 WordPress 沒有啟用頁面快取，每次請求都要跑 MySQL 查詢。加上 WP Rocket 全頁快取後，TTFB 降到 280ms，LCP 從 4.8 秒掉到 2.1 秒。圖片完全沒動。，詳見WordPress LCP 修復流程

消除資源加載延遲：preload 與 fetchpriority 實作

Resource load delay（資源加載延遲）指的是 HTML 收到後，瀏覽器發現 LCP 圖片並開始下載之前的等待時間。最常見的原因是 LCP 圖片藏在 CSS 或 JavaScript 裡，瀏覽器要先解析完這些資源才知道圖片的存在。解法是讓瀏覽器提前知道這張圖片很重要。

兩種工具，用途不同：

多數情況下，只要在 <img> 標籤加上 fetchpriority="high" 就夠了，不需要同時使用 preload。如果同時用兩個，反而可能導致圖片被重複請求。選一個用就好。

常見的錯誤：把 loading="lazy" 加在 LCP 圖片上。lazy loading 會讓瀏覽器延遲下載圖片，對頁面下方的圖片很好，但加在 LCP 圖片上會直接讓 LCP 爆掉。LCP 圖片不要加 loading="lazy"。

參考 Google 官方 LCP 優化指南中的 "Prioritize the LCP resource" 章節，裡面有詳細的 fetchpriority 實作說明。

LCP 圖片優化：壓縮之外你還能做什麼

圖片優化針對的是 resource load duration，雖然它在大多數網站中不是主要瓶頸，但如果你的 LCP 圖片確實超過 500KB，這一步值得做。

• 格式轉換：WebP 比 JPEG 小 25-35%，AVIF 比 WebP 再小 20%。優先推 WebP，AVIF 瀏覽器支援率已超過 95%，可以用 <picture> 標籤提供兩個版本。
• 正確的 srcset：不要對所有裝置提供同一張 1920px 的大圖。用 srcset 提供 400w/800w/1200w 不同尺寸，讓瀏覽器根據裝置選擇。行動裝置載入 400px 圖片比載入 1920px 快很多。
• width 和 height 屬性：在 <img> 標籤加上 width 和 height，讓瀏覽器在圖片載入前就保留版面空間，同時也有助於避免 CLS。
• CDN 圖片轉換：Cloudflare Images 或 BunnyCDN 可以自動在邊緣節點做 WebP 轉換和裁切，不需要手動處理不同尺寸。

特別要注意 CSS background-image：如果你的 LCP 元素是用 CSS background 定義的，瀏覽器要先下載並解析 CSS 才能發現這張圖片，這會造成很大的 resource load delay。能換成 <img> 標籤的話就換，不然就要加 preload。

延伸閱讀：Core Web Vitals 三大指標完整解析，了解 LCP、INP、CLS 在整體 CWV 評估中的比重。圖片格式選擇與壓縮的系統做法，參考圖片 SEO 優化指南。

排除渲染延遲：CSS、JavaScript 與字體對 LCP 的影響

Render delay（渲染延遲）是圖片下載完成後，到瀏覽器實際把元素繪製到螢幕上的這段時間。主要成因是 JavaScript 佔用了主執行緒（main thread），讓渲染任務排隊等待。

常見的渲染延遲原因和對應修法：

• Render-blocking JavaScript：在 <head> 裡沒有 async 或 defer 的 <script> 標籤，會阻斷 HTML 解析。加上 defer（大多數情況下比 async 安全）或把腳本移到 body 底部。
• Render-blocking CSS：所有 CSS 預設是 render-blocking。把非關鍵的 CSS（例如下方內容用到的樣式）移到 JavaScript inline 載入，或用 media 屬性過濾只載入當前 viewport 需要的樣式。
• 字體 FOIT/FOUT：自定義字體未載入時，文字可能變成 LCP 元素但顯示為空白（FOIT），造成渲染延遲。用 font-display: swap 讓瀏覽器先顯示系統字體，避免 FOIT。
• 大型 JavaScript 執行：如果有大量的 JS 在 onload 後跑（例如分析工具、A/B 測試腳本），可能佔用主執行緒延遲渲染。用 requestIdleCallback 或把這些任務推到 worker 執行。

可以在 DevTools Performance 面板的 Main 執行緒時間軸上，找到 LCP 時間點前後的長 task（紅色三角形警告）。那些就是需要分解或延後的執行任務。

如果你的網站有使用大量第三方腳本（Google Analytics、GTM、Hotjar、Facebook Pixel），參考JavaScript 對 SEO 的影響這篇文章，裡面有第三方腳本的載入策略說明。

WordPress 網站的 LCP 優化清單

WordPress 網站有一套常見的 LCP 問題模式，因為很多網站用了太多插件或預設的非最佳化設定。以下清單按照通常影響力排序：

1. 啟用全頁快取：WP Rocket、W3 Total Cache（Full Page Cache 功能）、或 LiteSpeed Cache（如果主機有 LiteSpeed）。這是對 TTFB 改善最直接的一步。
2. 設定 CDN：Cloudflare 免費方案或 BunnyCDN。把靜態資源分流到 CDN，不要讓圖片和 JS/CSS 直接從主機送出。
3. 關掉 LCP 元素上的 lazy load：Elementor、Divi 等頁面建構器預設會把所有圖片都加上 lazy load，包含 hero image。找到你的 LCP 元素，明確排除 lazy loading。
4. 啟用 WebP 轉換：ShortPixel、Imagify 或 WP Rocket 內建的圖片優化都可以批次轉換。
5. 移除不必要的插件：每個插件都可能載入額外的 CSS 和 JS。用 Query Monitor 確認哪些插件在哪些頁面載入了資源，刪掉不用的。
6. 啟用 Critical CSS：WP Rocket 的「Optimize CSS Delivery」選項可以提取關鍵 CSS inline，其餘 CSS 非同步載入，消除 render-blocking CSS。

更系統性的技術審查方法可以參考技術 SEO 完整稽核指南和在 GSC 確認 LCP 修復狀況這兩篇文章。

修完後怎麼驗證：field data 確認流程

修完 LCP 問題後，PSI 通常幾分鐘內就會顯示實驗室數據改善。但如果你盯著 GSC 的 Core Web Vitals 報告等待變化，可能要等上 4 週才看到。這不是修復沒效果，而是 CrUX 資料機制的正常運作。

驗證流程分三個階段：

1. 即時驗證（修復後當天）：用 PSI 跑 3-5 次確認實驗室 LCP 穩定低於 2.5 秒。用 Chrome DevTools Performance 面板確認 LCP 子部分的改善方向正確（目標子部分縮短了）。
2. 短期驗證（修復後 1-2 週）：如果網站有 GA4，可以在 Custom Reports 中查看 web-vitals 事件（需要有安裝 web-vitals.js）。這是比 CrUX 更快反映真實用戶資料的方式。
3. 長期確認（修復後 4-6 週）：GSC Core Web Vitals 報告中的 URL 狀態從「需要改善」或「不良」變更為「良好」。因為 CrUX 採用 28 天滾動窗口，頁面要維持良好 LCP 滿 28 天，GSC 才會更新狀態。

如果 PSI 已改善但 GSC 28 天後仍未更新，可以在 Google PageSpeed Insights API 的 Field Data 部分查看最新的 CrUX 數據，確認資料是否有在滾動更新中。也可以透過 Chrome UX Report BigQuery 資料集查詢特定 URL 的 p75 LCP 值。

關於如何用 GSC 追蹤修復進度，參考Google Search Console 中的 Core Web Vitals 報告解讀這篇文章的「驗證修復」章節。

LCP 優化的核心邏輯是：先診斷子部分，再決定修復方向。大多數網站的問題出在 TTFB 和 resource load delay，不是圖片大小。從 DevTools 拿到子部分數據後，按照 TTFB → 資源加載延遲 → 渲染延遲 → 圖片大小這個優先順序來修，通常效率最高。