PageSpeed 分數掉下來，你第一個想到的通常是「圖太大了」。有時候沒錯，但也可能是你把主視覺圖設成 loading="lazy"，等於請瀏覽器「晚點再叫主角上台」——LCP 當然跟著延後，比咖啡涼掉還難受。

LCP（Largest Contentful Paint）衡量的是：初次載入時，視窗內最大的文字、圖片或其他內容元素，何時完成繪製。這篇會帶你找出真正的 LCP 元素，分清楚 lazy、fetchpriority 與 preload 各自解決什麼問題，再用一套可以實際驗收的流程收尾。看完，你不必對著瀑布圖施法，也能知道下一杯咖啡該泡給誰。

目錄

先抓到你真正的 LCP 元素

先不要猜「應該是主視覺圖」。LCP 也可能是 H1、文章開頭的大段文字，或其他在初次視窗內佔面積最大的元素。流程如下：

  1. 開 PageSpeed Insights 或 Chrome DevTools → Performance 錄一次載入
  2. 看報告標出的 LCP 元素 是什麼（圖片、文字區塊或 H1）
  3. 記下它的 URL 或 DOM 節點，後面改碼才有對象

在 DevTools 的 Performance 面板中，也可以從 LCP 標記查看元素與時間。先確認「誰是 LCP」，再決定要不要調圖片；不然很容易把不是主角的圖片打扮成 VIP。

靜態網站常見的 LCP 來源包括主視覺圖、H1 標題與產品截圖。以真實使用者資料的評估方式來看，LCP 在第 75 百分位不超過 2.5 秒才算「良好」；這和 Lighthouse 的單次實驗室測試不是同一件事。想先搞懂欄位資料與實驗室資料的差異，可看站內 PageSpeed Insights 與 Core Web Vitals 2026。

決策表：lazy、fetchpriority、preload 怎麼選？

情境建議做法為什麼
確認是首屏內的 LCP 圖片不使用 loading="lazy"；必要時加 fetchpriority="high"讓瀏覽器及早發現並下載關鍵圖片
LCP 是 CSS 背景圖，或資源要等 JS 才出現<link rel="preload" as="image" fetchpriority="high">瀏覽器不容易從初始 HTML 直接發現它，需主動提示
內文圖、頁尾圖、側欄縮圖loading="lazy"讓頻寬先留給首屏內容
頁面有一、兩張真正關鍵的圖片只對那些圖片使用 fetchpriority="high"高優先級用太多，反而失去區分效果
本站的 Eleventy Transform 自動補上 lazy在主視覺圖上明確覆寫 loading="eager"內文圖的預設值不一定適合 LCP 圖

一句話心法：首屏 LCP 圖不要 lazy；確認是關鍵資源後再提高優先級；其餘圖片放心 lazy。

LCP 優化策略（核心：優先級 + 不被 lazy）

1. 不要 lazy-load LCP

最常見的壞操作，就是把首屏 LCP 圖片加上 loading="lazy"。瀏覽器通常要先完成版面計算，確認圖片接近視窗後才請求它；原本可以從 HTML 先發現的資源，就被迫排隊。下載、解碼、繪製每一步都往後，LCP 只好一起等。

<!-- ❌ 主視覺圖被延後載入 -->
<img src="/img/hero.webp" loading="lazy" alt="主視覺">

<!-- ✅ 首屏主角：不 lazy，並提示它很重要 -->
<img
  src="/img/hero.webp"
  alt="主視覺"
  width="1200"
  height="630"
  loading="eager"
  fetchpriority="high"
/>

eager 是明確表達「不要額外延後」；它不等於魔法加速器，真正的下載順序仍由瀏覽器決定。fetchpriority="high" 也是提示，不是命令。最後，別忘了補 width／height 預留版面，LCP 和 CLS 常常是同一張圖一起修。細節見站內 圖片最佳化與 CLS 解決方案。

2. 用 fetchpriority 把關鍵資源拉到前面

當 LCP 是圖片，而且瀏覽器發現它太晚時，方向是：

  • 主視覺圖：加 fetchpriority="high"
  • CSS 背景圖或 JS 稍後插入的圖片：在 <head> 視情況用 preload 宣告
<!-- CSS 背景 LCP：在 head 主動預載 -->
<link rel="preload" fetchpriority="high" as="image" href="/img/hero.webp" type="image/webp">

<!-- HTML 直接宣告的 LCP 圖 -->
<img
  src="/img/hero.webp"
  fetchpriority="high"
  alt="網站主視覺 Banner"
  width="1200"
  height="630"
/>

preload 解決的是「讓瀏覽器更早發現資源」；fetchpriority 解決的是「在已發現的資源中，提示相對重要性」。兩者可以搭配，但不是每張圖片都要一起上。fetchpriority="high" 請只給真正可能成為 LCP、而且確實需要提早下載的資源；大家都當 VIP，最後就沒有 VIP。

3. Eleventy 靜態站：管道預設 lazy 的陷阱

在本站，HTML Transform 會替沒有明確設定的圖片補上 loading="lazy"。這對文章中段的圖片通常合理，卻不一定適合首屏 LCP 圖。遇到這種情況，要在那張圖片上明確覆寫：

<img
  src="/img/hero.png"
  alt="產品主視覺"
  loading="eager"
  fetchpriority="high"
  sizes="(max-width: 800px) 100vw, 1200px"
/>

不要只看 HTML 屬性，也要在 build 後檢查實際輸出的 HTML，確認 loading、fetchpriority、srcset 與 sizes 都符合預期。接著檢查圖片的實際下載大小、尺寸與格式：手機只需要幾百像素寬，就別把幾千像素的原圖整包寄過去。WebP 或 AVIF 可以是選項，但最後仍要以實際檔案大小、畫質和瀏覽器支援情況驗收。

如果圖片是由 JavaScript 動態插入，瀏覽器會更晚才知道它存在。能直接寫進初始 HTML 就直接寫；真的必須動態產生時，至少確認它不是因為程式執行太晚才錯過下載時機：

const hero = document.querySelector('.hero-image');

hero.src = '/img/hero.webp';
hero.fetchPriority = 'high';

這段程式只是在 HTML 已經有圖片元素的前提下補上來源與提示；它不會讓 JavaScript 變成 preload。若資源本來就能在 <head> 預先宣告，優先考慮 HTML 的 preload。

4. 避免 render-blocking 讓首屏後面卡住

如果非關鍵 JS／CSS 形成很長的依賴鏈，LCP 圖片就算早早下載完成，也可能等不到繪製。快速檢查：

資源類型建議
非關鍵 JavaScript依載入需求考慮 defer 或 async；第三方標籤可在主要內容穩定後再載入
CSS避免不必要的 @import 串接；確認 CSS 沒有讓首屏繪製卡在長依賴鏈上
Web 字體使用 font-display: swap；只有確定是關鍵字體時才考慮 preload

GTM 延遲載入的具體寫法，可參考站內 GTM 延遲載入：用 requestIdleCallback 降低 PSI 的 TBT。

一個快速驗收心法：先 CLS 穩，再談 LCP

LCP 是「什麼時候畫出來」，CLS 是「版面有沒有抖」。兩者不是同一個指標，但同一張圖片可能同時影響兩者：沒有尺寸時會推動版面，有錯誤載入策略時又會晚到。

建議順序：

  1. 先確保圖片／嵌入不會讓版面在載入期抖動（CLS 預留）
  2. 再回頭把 LCP 圖片的優先級拉到位
  3. 最後用 GSC → 體驗 → Core Web Vitals 對欄位資料驗收；報告反映的是一段期間的真實使用者資料，不會改完立刻更新

框架快速對照

框架圖片管道LCP 注意事項
Hugoresources.Get + Resize／webp主視覺圖模板別加 lazy
Eleventy@11ty/eleventy-imgTransform 預設 lazy，主視覺圖覆寫 eager + fetchpriority
Astroastro:assets 或 <Image />依實際輸出與圖片位置確認 loading 設定，LCP 圖別盲目 lazy

快速驗收清單

每次修改後，按這個順序檢查：

  1. PSI 或 DevTools 是否指出同一個 LCP 元素？
  2. LCP 圖是否在初始 HTML 中可被發現？若是背景圖，是否真的需要 preload？
  3. 是否誤用了 loading="lazy"？fetchpriority="high" 是否只用在少數關鍵資源？
  4. build 後的 HTML、Network 瀑布圖與實際圖片大小是否符合預期？
  5. CLS 的尺寸預留是否仍然存在？

結語：LCP 優化是「不要拖關鍵資源」的工程紀律

  • 用 PSI／DevTools 找出真正的 LCP 元素，別憑感覺改
  • 首屏 LCP 圖不要 loading="lazy"；確認需要時再加 fetchpriority="high"
  • CSS 背景圖等難以被初始 HTML 發現的資源，才考慮 preload
  • Eleventy 管道若自動補上 lazy，主視覺圖要個別覆寫
  • 圖片下載完成不代表已經繪製；也要排查 CSS、字體與 JavaScript 的依賴鏈

先改一個真正的瓶頸，再重新測量；不要一次把整個 <head> 塞滿 preload，否則瀏覽器也會開始懷疑人生。等資料慢慢累積，再回 GSC 看真實使用者的趨勢。改完記得再來一杯，這次是慶祝主角準時登場的那杯。

參考資料