LCP 優化教學：改善最大內容繪製分數，讓首屏內容更快出現

LCP 是什麼？為什麼會影響 SEO 與使用者體驗

LCP 指 Largest Contentful Paint，中文常稱最大內容繪製，衡量的是使用者打開頁面後，首屏中最大一塊主要內容出現所花的時間；這裡的 LCP 是網站速度指標，不是電競聯賽。

對 SEO 和轉換來說，LCP 的價值很直接：使用者能不能快點看到他正在等的內容。首頁主視覺、文章封面、產品圖、H1 文字區塊，只要它是首屏中最大的可見內容，就可能成為 LCP 元素。

LCP 衡量的是哪一個畫面元素

LCP 不是整頁完全載入時間，而是 viewport 內最大圖片或文字區塊完成顯示的時間。實務上，先找出這個元素，比直接壓縮全站圖片更重要。

常見 LCP 元素：主視覺圖、H1 區塊、產品圖、封面圖

品牌官網常見是首頁主視覺圖，電商常見是產品主圖，內容站常見是文章封面或標題區塊。Kevin Lin 的判斷是：只要 LCP 元素還沒確認，任何優化清單都只能算猜測。

LCP 多少才算合格

Google Core Web Vitals 將 2.5 秒以內視為良好，2.5 到 4 秒為需要改善，超過 4 秒為不佳。檢查時要以手機版為優先，因為台灣使用者多數搜尋情境都發生在行動裝置。

2.5 秒以內、2.5 到 4 秒、超過 4 秒的判讀方式

2.5 秒內通常先維持監控；2.5 到 4 秒要找出模板或圖片問題；超過 4 秒則要同時檢查伺服器回應、首屏圖片、CSS、JavaScript 與第三方程式。

LCP 和 SEO、轉換率的關係

LCP 屬於 Core Web Vitals，也是頁面體驗的一部分。它不保證排名上升，但慢速頁面會降低搜尋體驗、降低使用者繼續閱讀或詢問的機率。對商業頁來說，慢的不只是分數，也是第一眼信任感。

先找出你的 LCP 元素與問題頁面

LCP 優化的第一步，是用 PageSpeed Insights、Search Console 和 Lighthouse 找出「哪個 URL 慢、哪個元素慢、慢在現場資料還是實驗室資料」。沒有這一步，容易改到不影響結果的地方。

1. 先用 Search Console 找出受影響 URL 群組。
2. 挑代表頁丟進 PageSpeed Insights。
3. 查看診斷結果中的 LCP 元素。
4. 用 Lighthouse 或瀏覽器開發者工具確認首屏資源。
5. 記錄手機版與桌機版差異。

用 PageSpeed Insights 找出 LCP 元素

PageSpeed Insights 會顯示 LCP 分數、現場資料、實驗室資料，並可能標出 LCP 元素。若看到主圖、封面圖或大段文字被標示，就先針對該元素處理，不要急著安裝一堆速度外掛。

用 Search Console 找出受影響 URL 群組

Search Console 的 Core Web Vitals 報告適合看 URL 群組。如果同一批文章頁都不佳，通常是模板、圖片尺寸、快取或廣告追蹤碼問題；如果只有單頁不佳，先看該頁的首屏素材。

現場資料與實驗室資料為什麼會不同

現場資料來自 Chrome 使用者體驗報告，反映真實使用者過去一段時間的體驗；實驗室資料是在固定環境下測試。實驗室資料適合找原因，現場資料適合判斷長期結果。

手機版與桌機版要分開看

同一頁在桌機版可能合格，手機版卻不佳。原因通常是手機網路、裝置效能、圖片尺寸、版面堆疊方式不同。只看桌機版分數，是很多網站誤判 LCP 的來源。

LCP 變慢的 7 個常見原因

LCP 變慢通常來自七類問題：圖片太重、伺服器回應慢、CSS 或 JavaScript 阻塞、首屏圖片錯誤 lazy load、字型等待、第三方程式拖慢、手機版版面過重。

主視覺圖片太大或格式不對

如果 LCP 元素是圖片，先看檔案大小、實際顯示尺寸與格式。很多網站在手機首屏顯示 400px 寬，卻讓手機下載桌機大圖，這種問題比少裝一個外掛更常見。

伺服器回應時間太慢

TTFB 慢會讓後面的圖片、CSS、文字都延後開始。判斷方式是看 PageSpeed Insights 的伺服器回應時間與瀑布圖，修法通常是頁面快取、主機調整、資料庫整理或 CDN。

CSS 或 JavaScript 阻塞主要內容顯示

如果首屏內容需要等大型 CSS 或 JavaScript 執行完才出現，LCP 會被拖住。這類問題要由工程檢查 render-blocking resources，而不是只在後台開一個壓縮選項。

首屏圖片被錯誤 lazy load

首屏 LCP 圖片不建議 lazy load，因為瀏覽器會延後請求最重要的圖片。判斷方式很簡單：被 PSI 標示為 LCP 的圖片，如果同時有 lazy loading，就應優先移除。

字型載入造成文字延遲顯示

當 LCP 元素是 H1 或大段文字時，字型可能讓文字延遲顯示。可檢查 web font 是否太多、是否阻塞文字顯示，並使用 font-display: swap 降低等待感。

第三方追蹤碼拖慢首屏

廣告、分析、客服、熱圖工具都可能搶首屏資源。建議先列出每個第三方程式的商業用途，沒有必要在第一秒執行的，就延後或移除。

手機版版面比桌機版更重

手機版常因輪播、動畫、背景影片、過多區塊堆疊而變重。我的實務觀察是，很多 LCP 問題不是技術不會修，而是首屏設計本身要求瀏覽器做太多事。

圖片型 LCP 怎麼優化

圖片型 LCP 的優化重點，是讓首屏最大圖片用正確格式、正確尺寸、正確載入優先級出現；優先處理 LCP 圖片，通常比全站無差別壓縮更有效。

• 確認 LCP 圖片是哪一張。
• 輸出 WebP 或 AVIF，保留必要的備援格式。
• 裁切成實際版面需要的尺寸。
• 首屏圖片不要 lazy load。
• 必要時加 preload 或 fetchpriority。

把首屏主圖改成 WebP 或 AVIF

WebP 和 AVIF 通常能降低圖片檔案大小，同時維持可接受的畫質。改完後要用 PSI 檢查 LCP 是否下降，也要用真實手機看圖片是否失真。

設定正確圖片尺寸，避免上傳超大圖

圖片寬度應接近實際顯示需求。桌機主圖、手機主圖可以用不同尺寸，不要讓手機下載不必要的大圖。WordPress 站尤其要檢查佈景主題是否正確產生縮圖尺寸。

為 LCP 圖片加上 preload

如果主圖是明確的 LCP 元素，可以用 preload 提早告訴瀏覽器優先下載。這適合固定模板的首頁、服務頁、產品頁，但不應對大量非首屏圖片濫用。

首屏圖片不要 lazy load

lazy load 適合首屏以下圖片，不適合 LCP 圖片。若 WordPress 外掛把所有圖片都自動 lazy load，要排除首頁主圖、文章首圖或產品主圖。

使用 responsive images 避免手機載入桌機大圖

使用 srcset 和 sizes，讓瀏覽器依裝置選擇合適圖片。驗證時可以用手機版 Lighthouse 或網路面板確認實際下載的圖片寬度與檔案大小。

文字或版面型 LCP 怎麼優化

當 LCP 元素是 H1、文字區塊或首屏容器時，重點會從圖片轉向字型、CSS、渲染順序與元件載入；這類問題常被忽略，卻會讓分數卡住。

用 font-display: swap 降低文字等待時間

font-display: swap 可以讓瀏覽器先用系統字型顯示文字，再替換成正式字型。這對文字型 LCP 特別有用，因為使用者至少能先看到內容。

減少首屏 CSS 阻塞

首屏需要的 CSS 應優先保留，首屏以下樣式可以延後。若使用大型佈景主題或頁面編輯器，要檢查是否載入了大量當頁用不到的樣式。

避免把重要內容放在太晚渲染的元件中

重要 H1、摘要、產品主資訊，不適合完全依賴很晚才執行的元件。對 SEO 內容頁來說，首屏主內容越早被瀏覽器和使用者看到，越不容易被技術流程拖慢。

伺服器、快取與 CDN 對 LCP 的影響

如果 TTFB 偏慢，LCP 會從一開始就落後；伺服器、快取與 CDN 的作用，是讓 HTML 與首屏資源更快送到台灣使用者裝置上。

先看 TTFB 是否過慢

TTFB 是瀏覽器等待伺服器第一個回應的時間。若 TTFB 慢，圖片再怎麼壓縮也會受影響。先看 PSI、Lighthouse 或伺服器監控，再決定是否處理主機與快取。

啟用頁面快取與瀏覽器快取

頁面快取能減少每次都重新產生 HTML 的成本，瀏覽器快取則能讓重複訪問者少下載相同資源。WordPress 站通常應先確認快取是否真的命中。

用 CDN 縮短台灣使用者的資源距離

CDN 對圖片、CSS、JavaScript 等靜態資源有幫助，尤其主機不在台灣或亞洲時更明顯。不過 CDN 不是萬用解法，若後端產生 HTML 很慢，仍要處理源頭。

移除或延後非必要第三方程式

追蹤碼要有使用目的。首頁首屏同時塞入多個行銷工具，常會讓 LCP 和 INP 都變差。保留必要分析，延後非必要腳本，通常比盲目升級主機更快看到差異。

WordPress 網站改善 LCP 的實作順序

WordPress 改善 LCP 應採取低風險順序：先備份與測試代表頁，再處理首屏圖片、快取、外掛、佈景主題和頁面編輯器，不要一次開啟所有最佳化功能。

1. 備份網站與資料庫。
2. 選首頁、文章頁、分類頁或產品頁作為代表頁。
3. 記錄修改前 PSI 與 Search Console 狀態。
4. 一次只改一類設定。
5. 改完立即測試前台版面與速度。

先備份，再測試單頁模板

先從代表模板開始，不要直接全站套用。文章頁、分類頁、產品頁各測一頁，才能知道問題是單頁素材，還是模板層級。

壓縮與轉換首屏圖片

WordPress 圖片外掛可以協助壓縮與轉換格式，但仍要人工確認首屏主圖沒有被錯誤 lazy load，且手機版沒有下載桌機大圖。

檢查快取外掛設定

快取外掛不是開了就有效。要確認頁面快取、瀏覽器快取、CSS/JS 最佳化是否正常，也要避免壓縮設定造成選單、表單或結帳流程壞掉。

檢查頁面編輯器與過重區塊

Elementor 或其他頁面編輯器常讓首屏載入額外樣式與腳本。若主視覺包含輪播、動畫、背景影片，應先判斷這些元素是否真的支持轉換。

不要一次開啟所有最佳化選項

一次開太多選項，分數變好或壞都難以追蹤。建議每次只改圖片、快取、CSS、JavaScript 或第三方程式其中一類，並留下紀錄。

LCP 優化優先順序：先改哪裡最有效

LCP 優化應先處理影響 URL 最多、商業價值最高、修正成本合理的問題；有限預算下，模板層級問題通常比單篇低流量文章更值得優先處理。

先處理影響最多 URL 的模板問題

如果同一個文章模板造成上百篇內容 LCP 不佳，優先級應高於單頁微調。模板修好後，受益的是整批 URL。

再處理首頁、分類頁、服務頁、產品頁

這些頁面通常承接品牌、搜尋與轉換任務。就算流量不是最高，只要商業價值高，也應排在前面。

最後才微調低流量文章頁

低流量文章可以用批次圖片壓縮、模板修正、快取規則處理，不需要每一篇都投入工程細修。

用改善前後數據判斷是否值得繼續投入

如果處理後 LCP 從不佳進入需要改善，下一步才評估是否繼續壓低。追求滿分常會消耗大量時間，但對使用者與商業結果不一定等比例回收。

LCP 改完後怎麼驗證

LCP 改完後要分短期與長期驗證：短期用 Lighthouse 或 PageSpeed Insights 看立即變化，長期用 Search Console 與實際使用者資料確認 28 天趨勢。

先用 Lighthouse 或 PSI 看立即變化

修改圖片、preload、快取或 CSS 後，可以立即用 Lighthouse 或 PSI 看 lab data 是否改善。若完全沒有變化，代表可能改錯元素，或快取尚未更新。

再等 Search Console 反映實際使用者資料

Search Console 的 Core Web Vitals 需要時間累積實際使用者資料。改完當天沒變，不代表失敗；真正判斷應看後續資料是否逐步改善。

記錄改動項目，避免分數波動時無法回溯

每次修改都應記錄日期、頁面、改動項目、測試結果。網站速度會受主機、流量、第三方程式影響，沒有紀錄很難知道是哪次修改造成變化。

不建議為了 LCP 做的事

LCP 優化不能只追分數；刪掉重要內容、錯誤 lazy load、在正式站一次套用大量壓縮，都可能讓速度分數變好，卻讓網站目的受損。

• 不要為了首屏變快刪掉使用者需要的資訊。
• 不要把所有圖片都設定 lazy load。
• 不要在正式站一次套用大量 CSS 或 JS 壓縮。
• 不要只看單次 PSI 分數判斷成敗。
• 不要忽略手機版實際體驗。

不要只為分數刪掉重要內容

如果首屏內容能幫助使用者理解產品、服務或文章主題，就不該只因分數刪除。更好的做法是降低資源成本，保留真正有用的內容。

不要把所有圖片都 lazy load

首屏以下圖片可以 lazy load，首屏 LCP 圖片不適合。這是 WordPress 外掛最常見的誤傷之一。

不要在正式站一次套用大量壓縮設定

CSS 合併、JavaScript 延後、移除未使用樣式，都可能影響互動功能。正式站應分批測試，尤其表單、選單、結帳與追蹤事件要逐一確認。

LCP 優化檢查清單

有效的 LCP 優化流程，是先找出 LCP 元素，再依圖片、伺服器、CSS、JavaScript、字型、第三方程式分類處理，最後用短期測試與長期資料驗證。

• 內部延伸閱讀可參考 Core Web Vitals。
• 圖片細節可參考 圖片 SEO 優化。
• 技術背景可搭配 Google 排名因素 2026。
• 安全與主機基礎可參考 HTTPS 與 SSL 設定。