LCP優化怎麼做？從診斷最大內容渲染到縮短首屏等待

LCP 是什麼？為什麼 2.5 秒是關鍵門檻

LCP 是最大內容渲染，衡量使用者打開網頁後，視窗內最大的主要內容花多久完成顯示。LCP 優化的目標，是讓 75% 實際使用者的 LCP 落在 2.5 秒內。

對網站負責人來說，LCP 不該只被看成技術分數。它更接近一個現場問題：使用者等多久才看到這頁真正要給他的內容。首頁的 Hero 圖、文章標題、商品主圖、首屏大段文字，都可能成為最大內容渲染的對象。

LCP 代表使用者多久看到主要內容

Largest Contentful Paint 看的不是第一個小圖示、第一行文字或背景顏色，而是首屏範圍內最大的內容區塊完成顯示的時間。這個設計很務實，因為使用者通常不在意網頁「開始有東西」，他在意主要內容是否真的出現。

LCP 分數怎麼看：良好、需改善、不良

LCP 區間	判定	實務解讀
2.5 秒內	良好	多數使用者能在可接受時間內看到主要內容
2.5-4 秒	需改善	已經有明顯等待感，手機流量通常會更吃虧
超過 4 秒	不良	需要優先處理，常見原因包含伺服器慢、圖片太重或渲染被阻塞

LCP 和 SEO 的關係：排名訊號之一，但核心價值是降低等待感

2026 年的 Core Web Vitals 主要由 LCP、INP、CLS 組成，FID 已經不是主指標。LCP 是頁面體驗訊號之一，但不要把它講成「改了就保證排名上升」。陳建宏會先把它當成使用者體驗問題處理：主要內容越晚出現，使用者越容易離開，電商頁與詢問表單頁尤其明顯。若要理解整組指標的關係，可延伸看 Core Web Vitals 完整指南。

先找出 LCP 元素：不要還沒診斷就開始壓圖片

LCP 優化第一步不是壓縮圖片，而是找出目前這個 URL 的 LCP element。只有知道最大內容渲染是哪個元素，才知道該修圖片、文字、影片 poster、背景圖，還是 JavaScript 動態內容。

很多網站一看到 LCP 慢，就先把全站圖片重壓一輪。這種做法有時有效，但也常浪費時間。尤其是圖片檔案不大、卻被 CSS、JS、字體或伺服器回應拖慢時，單純壓縮圖片不會碰到真正瓶頸。

用 PageSpeed Insights 查看 Largest Contentful Paint element

1. 打開 PageSpeed Insights，輸入要檢查的 URL。
2. 先分開看手機與桌機，不要把兩者平均。
3. 在診斷項目中找到「Largest Contentful Paint element」。
4. 查看 PSI 指出的元素截圖、HTML 片段與建議。

如果 PSI 顯示的是 Hero 圖，通常優先查圖片尺寸、格式、載入優先級與 lazy loading。如果顯示的是 H1 或大段文字，就要看字體載入與 CSS 阻塞。如果顯示的是背景圖，通常要回頭檢查 CSS 何時被發現與下載。

用 Chrome DevTools Performance 找 LCP marker

Chrome DevTools 適合用來看單次載入過程。開啟 Performance 面板後錄製頁面載入，時間軸上會出現 LCP marker。點擊 marker 後，可以看到對應元素，以及它出現在整段載入流程的哪個位置。

這裡的重點不是學完整 DevTools，而是回答三個問題：LCP 元素是什麼、它的資源何時開始下載、資源下載完後為什麼還沒顯示。若 LCP 資源很晚才出現在網路請求中，問題常在 Resource Load Delay。若資源早就下載完，畫面卻晚很久才顯示，就要查 Element Render Delay。

用 Search Console 判斷是單頁問題還是模板問題

Google Search Console 的 Core Web Vitals 報表適合判斷範圍。如果只有單一 URL 失敗，通常是該頁內容或圖片配置有問題。如果一整組相似 URL 都失敗，例如所有商品頁、所有文章頁、所有分類頁，那多半是模板、外掛、前端框架或伺服器快取策略造成。

觀察結果	可能原因	先找誰處理
只有首頁 LCP 慢	Hero 圖、首頁動畫、第三方模組	網站維護者或前端工程師
所有文章頁都慢	文章模板、字體、廣告碼、快取設定	網站維護者
所有商品頁都慢	商品圖、推薦模組、個人化內容、後端查詢	電商工程或網站公司
全站都慢	TTFB、主機、CDN、HTML 快取	主機維護者或後端工程師

先判斷 LCP 是圖片型、文字型、影片型、背景圖或 JS 插入

LCP 元素類型	常見畫面	主要修正方向
圖片型	Hero 圖、商品主圖、文章封面	尺寸、格式、srcset、fetchpriority、preload
文字型	H1、大段首屏介紹文字	字體載入、Critical CSS、避免文字被 JS 延後產生
影片型	首屏影片封面	把 poster 當圖片優化，避免影片本體阻塞首屏
背景圖	CSS background-image Hero 區塊	讓資源更早被發現，避免被深層 CSS 延後
JS 插入內容	前端渲染後才出現的標題、卡片、推薦內容	SSR、SSG、減少 hydration 等待、拆分非必要 JS

LCP 優化前，先用四段時間找出真正瓶頸

LCP time 可以拆成 TTFB、Resource Load Delay、Resource Load Duration、Element Render Delay。LCP 優化要先看哪一段占比最高，再決定修伺服器、資源發現、檔案大小或渲染延遲。

這是整個診斷流程最重要的一步。只看總秒數，大家只能猜；拆成四段後，才知道該動哪個環節。我的判斷標準很直接：先修占比最大的段落，再修最容易造成連鎖延遲的段落。

四段時間	意思	常見症狀	優先修法
TTFB	瀏覽器等到第一個 HTML 回應的時間	所有資源都很晚開始	快取、CDN、主機、後端查詢
Resource Load Delay	HTML 回來後，瀏覽器多久才發現 LCP 資源	圖片不大，但很晚才開始下載	preload、fetchpriority、調整 HTML 結構、避免 lazy load
Resource Load Duration	LCP 資源本身下載多久	資源下載時間很長	WebP、AVIF、壓縮、srcset、CDN
Element Render Delay	資源到位後，元素多久才真正顯示	資源下載完，畫面仍卡住	Critical CSS、延後 JS、減少 hydration、處理主執行緒阻塞

TTFB 太高：先修伺服器，不要只修前端

TTFB 是 Time to First Byte，代表瀏覽器送出請求後，等到伺服器第一個位元組回來的時間。當 TTFB 太高，HTML 還沒回來，瀏覽器無法解析頁面，也無法發現圖片、CSS 或 JS。

這種情況下，前端工程師把圖片壓小會有改善，但改善幅度有限。應優先檢查 HTML 快取、CDN edge cache、主機資源、後端資料庫查詢、SSR 產頁速度。WordPress 網站若未啟用頁面快取，LCP 常常從一開始就輸在 TTFB。

Resource Load Delay 太高：瀏覽器太晚發現 LCP 資源

Resource Load Delay 指 HTML 回來後，到瀏覽器開始下載 LCP 資源之間的等待時間。這段過高時，常見畫面是 Hero 圖其實不大，但網路請求中很晚才開始下載。

常見原因包含首屏圖片被 lazy load、圖片藏在 CSS background-image、圖片由 JavaScript 動態插入、preload 沒設、或資源優先級太低。這是很多網站被誤判的地方：檔案大小沒問題，問題在瀏覽器太晚知道它需要這個檔案。

Resource Load Duration 太高：資源本身太大或傳太慢

Resource Load Duration 高，代表 LCP 資源一旦開始下載，仍花太久才完成。圖片型 LCP 最常見，尤其是桌機上傳 3000px 寬原圖，手機卻只顯示 390px 寬，還沒有 WebP、AVIF 或 srcset。

處理方式是把圖片壓到實際顯示需要的尺寸，提供現代格式，透過 srcset 讓不同螢幕拿到合適版本，再搭配 CDN 降低傳輸距離。這一段不該靠單一壓縮外掛賭運氣，因為錯誤尺寸仍會讓手機吃下過大的檔案。

Element Render Delay 太高：資源到了但畫面還沒渲染

Element Render Delay 指 LCP 資源已經可用，但瀏覽器仍沒把元素畫到畫面上。原因常見於 render-blocking CSS、主執行緒被 JavaScript 卡住、自訂字體阻塞文字顯示，或 SPA hydration 還沒完成。

前端網站常發生這種狀況：LCP 圖片下載完了，但頁面要等框架完成初始化、元件掛載、資料請求回來後才顯示主要內容。這時要減少首屏依賴 JS 的程度，讓主要內容盡量在 HTML 或伺服器渲染階段就能出現。

看到哪種數據，就先做哪種修正

你看到的現象	優先懷疑	第一個修正動作
HTML 很晚才回來	TTFB	查快取、CDN、主機與後端查詢
LCP 圖很晚才開始下載	Resource Load Delay	移除 lazy load，補 preload 或 fetchpriority
LCP 圖下載很久	Resource Load Duration	壓縮、改格式、做 srcset
資源下載完仍晚顯示	Element Render Delay	查 CSS、JS、hydration、字體阻塞

為什麼「圖片不大但 LCP 還是慢」通常是發現太晚

如果一張 80KB 的 Hero 圖仍造成 3 秒以上 LCP，通常不要先怪圖片大小。更合理的檢查順序是：它是不是被 lazy loading、是不是背景圖、是不是由 JS 產生、是不是 CSS 太晚載入後瀏覽器才知道要抓這張圖。LCP 優化真正要改的是等待鏈條，不只是檔案體積。

圖片型 LCP 優化：格式、尺寸、載入優先級一次處理

圖片型 LCP 要同時處理尺寸、格式、響應式圖片與載入優先級。首屏 LCP 圖通常不該 lazy load，應讓瀏覽器早點發現、早點下載，並拿到剛好適合裝置的圖片版本。

不要把首屏 LCP 圖片設成 lazy load

lazy loading 適合折線以下圖片，不適合首屏最大內容。首屏 Hero 圖或商品主圖若加上 loading="lazy"，瀏覽器可能延後下載，直接拉高 Resource Load Delay。

錯誤示例：

<img
  src="/images/hero.jpg"
  alt="網站建置服務"
  loading="lazy"
  width="1200"
  height="630">

較合理的做法是讓首屏 LCP 圖直接被發現，並視情況提高優先級：

<img
  src="/images/hero.webp"
  alt="網站建置服務"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async">

把圖片尺寸縮到實際顯示需要，不要直接上傳原圖

圖片尺寸要以實際顯示尺寸與裝置密度規劃。若手機版 Hero 只顯示 390px 寬，卻下載 2400px 寬圖片，Resource Load Duration 會被不必要地拉長。WordPress、Shopify 或客製網站都一樣，原圖可以保留在後台，但前台輸出要用適合尺寸。

做錯的代價很明確：手機使用者下載過大的圖片，LCP 變慢，流量成本也變高。電商網站尤其常見，因為商品圖為了細節清楚而上傳大圖，但列表與首屏主圖沒有分尺寸輸出。

使用 WebP / AVIF 與 srcset 提供響應式圖片

WebP 與 AVIF 通常能在畫質可接受的前提下降低檔案大小，但格式不是唯一答案。更重要的是搭配 srcset 與 sizes，讓瀏覽器依照螢幕寬度選擇合適檔案。

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-640.avif 640w, /images/hero-1200.avif 1200w">
  <source
    type="image/webp"
    srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w">
  <img
    src="/images/hero-1200.jpg"
    srcset="/images/hero-640.jpg 640w, /images/hero-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="LCP 優化範例"
    width="1200"
    height="630"
    fetchpriority="high">
</picture>

fetchpriority="high"、preload、lazy loading 該怎麼選

方法	什麼情況該做	怎麼判斷	做錯會怎樣
fetchpriority="high"	LCP 圖已在 HTML 中，但需要提高下載優先級	DevTools 看到圖片早被發現，但優先級不高	太多資源都設 high，會互搶頻寬
preload	LCP 資源太晚才被發現，例如 CSS 背景圖	Resource Load Delay 明顯偏高	濫用會讓不重要資源搶在首屏前下載
lazy loading	折線以下圖片、非首屏圖片	元素不在初始視窗內	用在 LCP 圖會讓主要內容更晚出現

<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
  imagesrcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
  imagesizes="(max-width: 768px) 100vw, 1200px">

背景圖成為 LCP 時，為什麼比 <img> 更難優化

背景圖通常藏在 CSS 裡，瀏覽器要先取得 HTML、發現 CSS、下載 CSS、解析後才知道還要抓背景圖。這條路徑比直接在 HTML 出現的 <img> 更長，所以容易拉高 Resource Load Delay。

若背景圖就是首屏主要內容，可以考慮改成 <img> 或 <picture>，再用 CSS 做裁切與定位。若必須保留 background-image，就要評估 preload，但只該針對真正的 LCP 背景圖使用。

文字型、影片型、動畫型 LCP 怎麼優化

LCP 不一定是圖片。文字、影片 poster、背景圖、動畫容器與 JavaScript 插入內容都可能成為最大內容渲染元素。不同元素類型要用不同修法，誤判會讓優化方向整個偏掉。

H1 或大段文字是 LCP：先處理字體阻塞

當 H1 或首屏大段文字是 LCP，通常要檢查 CSS 與字體。若自訂字體下載前文字被隱藏，使用者會看到空白或延遲出現的標題。這類問題表面上不是圖片，但等待感一樣明顯。

判斷方式是看 PSI 的 LCP element 是否指向文字節點，並在 DevTools 中檢查字體請求與樣式載入。若文字晚於 HTML 很久才出現，優先查字體策略與 render-blocking CSS。

自訂字體造成延遲：使用 WOFF2、font-display、系統字體備援

自訂字體應使用 WOFF2，並設定 font-display: swap 或符合設計需求的顯示策略。系統字體備援也要合理，避免字體未載入時畫面完全空白。

@font-face {
  font-family: "BrandSans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}
body {
font-family: “BrandSans”, -apple-system, BlinkMacSystemFont, “Segoe UI”, sans-serif;
}

做錯會造成兩種問題：文字等字體載入才顯示，或字體切換時版面跳動。前者拖慢 LCP，後者可能影響 CLS。這篇不展開 CLS，但實作時不能只顧一個指標。

影片 poster 是 LCP：把 poster 當圖片優化

首屏影片常把 poster 當成最大內容。這時不要急著優化影片本體，先把 poster 當圖片型 LCP 處理：尺寸要正確、格式要合適、不要 lazy load、必要時設定較高優先級。

影片本體應避免在首屏載入時搶太多資源。對企業官網與活動頁來說，首屏自動播放影片很常拉高 LCP。我的建議是先讓 poster 快速出現，再把影片載入延後到互動或主要內容顯示後。

動畫或 JS 插入內容是 LCP：減少首屏等待與動態渲染

如果 LCP 元素由 JavaScript 插入，例如首頁大型輪播、商品推薦卡、前端框架產生的標題區，瓶頸常在 Element Render Delay。瀏覽器可能已經拿到資料與資源，但還要等 JS 執行、元件渲染或 hydration 完成。

元素類型	常見瓶頸	建議修法
H1 文字	字體阻塞、CSS 太重	font-display、系統字體備援、Critical CSS
大段文字	JS 產生內容、樣式延遲	讓內容在 HTML 中先輸出
影片 poster	poster 未優化、影片搶資源	poster 圖片優化，影片延後載入
動畫區塊	動畫庫與初始化阻塞	先顯示靜態首屏，再啟動動畫
JS 插入內容	CSR、hydration、資料請求	SSR、SSG、dynamic import、減少首屏依賴

CSS、JavaScript 與渲染延遲：讓主要內容早點出現在畫面上

資源下載完成不代表 LCP 已完成。若 CSS 阻塞渲染、JavaScript 卡住主執行緒，或框架 hydration 太晚，主要內容仍會延後出現在畫面上，形成 Element Render Delay。

移除或延後非必要 JavaScript

首屏不需要的 JavaScript 應延後載入，例如聊天工具、熱圖、非必要動畫、推薦模組、A/B 測試腳本。判斷方式是看 Performance 面板中的 long task，以及 LCP 前是否有大量 script 執行。

使用 defer 適合不需要阻塞 HTML 解析的腳本，async 適合彼此獨立、載完即可執行的第三方腳本。但追蹤碼不是越早越好，若它搶在主要內容前執行，會讓使用者先等分析工具，再等頁面內容，這個順序很不值得。

減少 render-blocking CSS，保留首屏 Critical CSS

render-blocking CSS 會讓瀏覽器等樣式表下載與解析後才繪製內容。LCP 優化要確保首屏必要樣式優先到位，非首屏樣式可以拆分或延後。

WordPress 常見問題是主題與外掛把全站樣式一次載入，文章頁也載入表單、輪播、電商樣式。SPA 或客製站則常見 CSS bundle 過大，導致首屏內容被不相干的樣式拖慢。修正時不必追求把所有 CSS 內嵌，而是讓首屏需要的 CSS 先到，其他樣式不要擋路。

React / Vue / Next.js：SSR、SSG、hydration 會影響 LCP

React、Vue、Next.js 網站要特別看首屏內容是否能在 HTML 中被直接看到。如果主要內容要等 client-side rendering 才產生，LCP 容易偏慢。Next.js 可依頁面特性選擇 SSG、SSR 或串流渲染，但不要讓所有首屏內容都依賴瀏覽器端資料請求。

hydration 是前端框架把伺服器產出的 HTML 接上互動能力的過程。若 hydration 太重，使用者雖然收到 HTML，畫面仍可能被大量 JS 工作拖住。電商頁的規格選擇器、推薦模組、個人化區塊，可以用 dynamic import 延後，不要跟商品主圖與標題搶首屏。

第三方追蹤碼、聊天工具、推薦模組不要搶首屏資源

第三方 script 是 LCP 優化最容易被低估的因素。行銷團隊常想保留所有追蹤，但技術上要分優先級。Google Tag Manager、聊天工具、熱圖、廣告、推薦引擎若全部在首屏前啟動，會增加網路請求與主執行緒工作。

比較好的做法是把必要追蹤保留在合理位置，非必要工具延後到 LCP 後或使用者互動後。若要和轉換設計一起評估，可參考 電商轉換設計，因為速度與轉換元件的優先順序常常要一起決策。

TTFB、CDN 與快取：伺服器太慢時，前端優化救不了多少

TTFB 高代表 HTML 回應太慢，瀏覽器在拿到頁面前無法開始解析主要資源。當伺服器回應是 LCP 主因時，應先處理快取、CDN、主機資源與後端查詢。

TTFB 高代表什麼：HTML 還沒回來，瀏覽器什麼都做不了

TTFB 是整條載入鏈的起點。若 HTML 1 秒多甚至更久才回來，後面的 CSS、圖片、字體、JS 全都被延後。這時候只做圖片壓縮，等於在後半段省時間，卻沒處理最前面的等待。

判斷方式很清楚：在 PSI、WebPageTest 或 DevTools Network 看 document request 的等待時間。如果 document 本身慢，先查伺服器與快取。如果 document 很快，但 LCP 圖晚下載，再回到 Resource Load Delay。

使用 CDN、HTML 快取與靜態資源快取

CDN 可以縮短使用者與資源之間的距離，靜態資源快取可以減少重複下載，HTML 快取則能降低後端每次產頁成本。對內容站、企業官網與多數 WordPress 網站來說，HTML 快取通常是降低 TTFB 的關鍵。

如果你正在規劃主機與架構，可延伸看 雲端主機選擇指南。但 LCP 診斷時不要先陷入主機商比較，應先確認目前是否有快取命中、CDN 是否正確服務台灣使用者、動態頁是否每次都打到後端。

WordPress 常見原因：外掛、主題、資料庫查詢、未快取頁面

WordPress LCP 慢常見於未啟用頁面快取、外掛太多、主題載入過重、資料庫查詢慢。尤其是首頁與文章頁，如果每次訪問都要 PHP 重新組頁、查資料庫、跑外掛邏輯，TTFB 很難穩定。

優先順序通常是：先啟用可靠頁面快取，再檢查主題與外掛輸出的 CSS/JS，接著處理圖片與字體。若還在選 CMS，可參考 CMS 選擇指南 2026，因為系統架構會直接影響後續效能維護成本。

電商常見原因：個人化模組、商品推薦、追蹤碼與後端查詢

電商網站的 TTFB 與 LCP 問題更複雜，因為商品價格、庫存、推薦、會員狀態、購物車與追蹤碼都可能影響首屏。商品頁若要等個人化推薦或後端查詢完成才顯示主圖與標題，LCP 很容易被拖慢。

做法是把首屏必要內容與非必要個人化模組切開。商品主圖、商品名、價格與主要購買資訊要先出現，推薦模組與行銷腳本可以延後。相關網站規劃可參考 電商網站架設指南 與 電商平台比較。

PageSpeed Insights 怎麼判讀：真實資料和測試資料不要混在一起看

PageSpeed Insights 上方通常是真實使用者資料，來自 CrUX；下方是 Lighthouse 實驗室測試。LCP 優化要分開看 Field data 與 Lab data，也要分開看手機與桌機。

Field data 和 Lab data 差在哪

Field data 是實際使用者資料，反映真實裝置、網路與地區條件。Lab data 是在固定模擬環境下測出來的結果，適合快速驗證修改方向。兩者用途不同，不應互相取代。

資料類型	來源	適合用途	限制
Field data	CrUX 實際使用者資料	判斷 Google 看到的真實體驗趨勢	需要累積流量，改善不會立刻反映
Lab data	Lighthouse 模擬測試	快速找問題、驗證單次修改	受測試環境影響，可能與真實資料不同

URL 層級和 Origin 層級代表不同範圍

URL 層級代表特定頁面的真實使用者資料，Origin 層級代表整個網域的彙整資料。若某頁流量不足，PSI 可能只顯示 Origin 資料。這時不能直接斷言該 URL 已經合格，只能說整個網域層級大致如此。

實務上，我會用 URL 資料判斷重點頁，用 Origin 資料看整站趨勢，再用 Search Console 查看是否有一組相似 URL 被歸在同一個問題群組。

手機 LCP 通常比桌機差，不能混在一起平均

手機 LCP 通常比桌機差，原因包含 CPU 較弱、網路條件較不穩、圖片尺寸策略錯誤、JS 執行成本較高。台灣流量若手機占比高，手機 LCP 應優先處理。

不要用桌機漂亮分數安慰自己。若手機 Field data 不合格，實際使用者仍在等待。尤其是電商、預約、詢價頁，手機體驗通常比桌機更接近真實轉換現場。

為什麼 PageSpeed Insights 每次測出來都不一樣

PSI 的 Lab data 每次測出來不同是正常現象，會受伺服器狀態、網路波動、第三方資源、測試節點與頁面快取影響。判讀時不要盯著單次分數，要看 LCP 元素是否一致、瓶頸段落是否一致、修改後趨勢是否變好。

常見誤解	正確判讀
PSI 測一次過關就代表完成	Lab data 可快速驗證，仍要等 Field data 累積
桌機快就代表整站快	手機與桌機應分開看
Lighthouse 分數是唯一目標	LCP 元素、四段時間與真實使用者資料更重要
Origin 合格代表每個 URL 都合格	重點頁仍需看 URL 層級與 Search Console 群組

不同網站類型的 LCP 優化優先順序

不同網站架構的 LCP bottleneck 不同。WordPress 多半先查快取、圖片、主題與外掛；電商要查商品圖、追蹤碼與個人化；SPA 則要看 SSR、SSG 與 hydration。

WordPress：快取、圖片、主題 JS、外掛

WordPress 的第一優先通常是頁面快取與圖片輸出。若 TTFB 高，先處理快取與主機。若 LCP element 是 Hero 圖或文章封面，再處理圖片尺寸、WebP、AVIF、srcset 與載入優先級。

外掛不是越少越好，而是不要讓每個外掛都在每個頁面載入資源。表單外掛只在表單頁需要，輪播外掛只在有輪播的頁面需要。這種資源治理，比單純追求外掛數量更有用。

電商網站：商品圖、追蹤碼、推薦模組、個人化內容

電商 LCP 常被商品主圖、追蹤碼與推薦模組拖慢。商品圖要做響應式尺寸，追蹤碼要管載入順序，推薦模組不要擋商品主內容。若商品頁 TTFB 高，還要檢查後端查詢與快取策略。

Shopify 或其他平台也一樣，主題與 App 可能把大量資源塞進首屏。先確認商品主圖與核心購買資訊能快速出現，再處理加購、推薦、評論、客服與行銷腳本。

React / Vue / Next.js：SSR、SSG、hydration、dynamic import

SPA 或前端框架網站要看主要內容是否靠瀏覽器端渲染。如果 LCP element 要等 API 回來、JS bundle 載完、hydration 完成才出現，就要重新安排渲染策略。

內容固定或半固定的頁面，可優先考慮 SSG。需要即時資料的頁面，可用 SSR，但要控制後端回應與快取。非首屏元件用 dynamic import，避免整包 JS 阻塞主要內容。

企業官網：Hero 圖、字體、首頁動畫、第三方表單

企業官網常見問題是首屏太重：大圖、品牌字體、動畫、影片、第三方表單與追蹤碼同時載入。這類網站通常頁面不多，最有效的作法是逐頁查 LCP element，從首頁與服務頁先修。

網站類型	常見瓶頸	優先修法	負責角色
WordPress	快取不足、Hero 圖、主題與外掛資源	HTML 快取、圖片輸出、資源分頁載入	網站維護者
電商網站	商品圖、推薦模組、追蹤碼、後端查詢	商品主內容優先、模組延後、快取與 CDN	電商工程或網站公司
React / Vue / Next.js	CSR、bundle 過大、hydration	SSR、SSG、dynamic import、減少首屏 JS	前端工程師
企業官網	Hero 圖、字體、動畫、第三方表單	圖片與字體優化、動畫延後、表單延後載入	網站公司或前端工程師

LCP 優化檢查表：從診斷到驗證的工作流程

LCP 優化流程應先確認是否超過 2.5 秒，再找 LCP 元素，接著拆四段時間，依瓶頸選修法，最後用 PSI、Search Console 與 CrUX 追蹤 Field data。

第一步：確認 LCP 是否真的超過 2.5 秒

先用 PageSpeed Insights 看手機與桌機的 LCP，並確認是 URL 層級還是 Origin 層級。若 75% 實際使用者已在 2.5 秒內，優先級可以降低；若手機超過 2.5 秒，且頁面是流量或轉換重點頁，就應排入修正。

第二步：找出 LCP 元素

用 PSI 的 Largest Contentful Paint element 與 DevTools 的 LCP marker 確認元素。不要用猜的，因為 LCP 可能是圖片、H1、影片 poster、背景圖或 JS 插入內容。找錯元素，後面所有修法都會偏。

第三步：拆四段時間

把 LCP 拆成 TTFB、Resource Load Delay、Resource Load Duration、Element Render Delay。先看最大段落，再看是否有連鎖問題。例如 TTFB 高會讓全部資源晚開始，Resource Load Delay 高則代表瀏覽器太晚發現 LCP 資源。

第四步：依瓶頸選修法

瓶頸	優先級	修正方向	驗證方式
TTFB 高	高	HTML 快取、CDN、主機、後端查詢	Document request 變快
LCP 資源發現太晚	高	移除 lazy load、preload、fetchpriority、調整 HTML	LCP 請求更早開始
資源下載太久	中高	WebP、AVIF、srcset、壓縮、CDN	資源大小與下載時間下降
渲染延遲	中高	Critical CSS、延後 JS、減少 hydration、處理字體	資源到位後更快顯示

第五步：用 PSI、GSC、CrUX 追蹤改善

修正後可以立刻用 Lighthouse 或 PSI Lab data 快速驗證，但 Search Console 與 CrUX 的 Field data 需要累積實際使用者資料。若 Lab data 明顯改善，Field data 卻沒有改善，要回頭看手機真實流量、慢速網路、地區差異與第三方資源波動。

檢查項目	完成標準
確認 LCP 數值	手機與桌機分開看，目標 2.5 秒內
找出 LCP element	PSI 與 DevTools 指向一致或能解釋差異
拆四段時間	知道主要瓶頸在哪一段
套用對應修法	不亂加 preload，不讓首屏 LCP lazy load
追蹤真實資料	GSC 與 CrUX 趨勢逐步改善

LCP 一定是圖片造成的嗎？

不一定。LCP 可能是圖片，也可能是 H1、大段文字、影片 poster、CSS 背景圖或 JavaScript 動態插入的內容。正確做法是先用 PageSpeed Insights 或 DevTools 找出 LCP element，再決定修法。

LCP 和 FCP 有什麼差別？

FCP 是 First Contentful Paint，代表第一個內容出現在畫面上的時間。LCP 是 Largest Contentful Paint，代表首屏最大主要內容完成顯示的時間。FCP 早不代表 LCP 好，因為使用者可能先看到小元素，真正重要的內容仍然很晚才出現。

LCP 要多少秒才算合格？

LCP 在 2.5 秒內算良好，2.5-4 秒屬於需改善，超過 4 秒是不良。Google 判斷時看的是實際使用者資料中第 75 百分位的表現，所以不能只看單次測試結果。

為什麼圖片不大，LCP 還是很慢？

圖片不大但 LCP 慢，常見原因是瀏覽器太晚發現圖片，也可能是 TTFB 高、CSS 或 JavaScript 阻塞渲染、自訂字體延遲。這時要看 Resource Load Delay 與 Element Render Delay，而不是只看檔案大小。

首屏圖片可以 lazy load 嗎？

通常不建議。若首屏圖片是 LCP element，lazy loading 會讓瀏覽器延後下載，直接拉高 LCP。lazy loading 應用在折線以下圖片，首屏主要圖片應優先載入。

preload 和 fetchpriority="high" 差在哪？

preload 是讓瀏覽器更早發現資源，適合 LCP 資源藏在 CSS 或太晚才被解析的情況。fetchpriority="high" 是提高已被發現資源的下載優先級，適合 HTML 中的首屏 LCP 圖。兩者都不要濫用，否則會讓太多資源互搶優先順序。

PageSpeed Insights 每次測出來 LCP 不同正常嗎？

正常。PSI 的 Lab data 會受網路、伺服器狀態、第三方資源、快取與測試環境影響。判讀時要看趨勢、LCP element 是否一致，以及主要瓶頸是否一致，不要只看單次秒數。

手機 LCP 比桌機差怎麼辦？

先分開看手機資料，不要用桌機平均掩蓋問題。手機 LCP 優化優先查圖片尺寸、JavaScript 執行成本、字體載入、TTFB 與第三方 script。若手機是主要流量來源，手機 LCP 的優先級應高於桌機。

LCP 優化會直接提升 Google 排名嗎？

LCP 是頁面體驗訊號之一，但不能保證改善後排名一定上升。它更直接的價值是降低等待感，讓使用者更快看到主要內容，進而影響停留、互動與轉換表現。

WordPress 最常見的 LCP 問題是什麼？

常見問題包含頁面快取不足、Hero 圖過大、文章封面沒有合適尺寸、外掛載入太多 JavaScript、主題 CSS/JS 過重，以及自訂字體阻塞。建議先看 TTFB，再找 LCP element，最後處理圖片與渲染延遲。

電商網站 LCP 慢通常要先查什麼？

先查商品主圖、首屏推薦模組、追蹤碼、個人化內容與 TTFB。商品主圖若太大或太晚載入會拖慢 LCP，推薦模組與追蹤碼若搶在主要內容前執行，也會讓首屏變慢。

LCP 改完後多久會反映在 Search Console？

Lab data 可以在修改後立即測到變化，但 Search Console 與 CrUX 使用 Field data，需要累積實際使用者資料才會反映。通常要看一段時間的趨勢，不要期待修完當天 Search Console 立刻變成良好。