PageSpeed 分數掉下來，你第一個想到的通常是「圖太大了」。有時候沒錯，但有時候更慘的是：你把主視覺圖設成 loading="lazy"，等於叫瀏覽器故意晚一點載入主角——LCP 當然跟著往後延，比咖啡涼掉還難受。
LCP（Largest Contentful Paint）量的是「首屏最大的那個元素，什麼時候真的被畫出來」。這篇只做一件事：把 LCP 優化拆成可以動手驗收的策略，並把你最容易踩的坑講清楚。如果你剛處理完 CLS（圖片預留寬高），這篇剛好接著把「載入速度」補齊。
目錄
先抓到你真正的 LCP 元素
不要猜「應該是主視覺圖」。流程是：
- 開 PageSpeed Insights 或 Chrome DevTools → Performance 錄一次載入
- 看報告標出的 LCP 元素 是什麼（圖片、文字區塊或 H1）
- 記下它的 URL 或 DOM 節點，後面改碼才有對象
靜態網站常見 LCP 來源：主視覺圖、H1 標題、產品截圖。Google 2026 門檻仍是 LCP ≤ 2.5 秒（CrUX 第 75 百分位），不是 Lighthouse 實驗室分數。想先搞懂欄位資料 vs 實驗室差異，可看站內 PageSpeed Insights 與 Core Web Vitals 2026。
決策表：lazy、fetchpriority、preload 怎麼選？
| 情境 | 建議做法 | 為什麼 |
|---|---|---|
| 確認是 LCP 的主視覺圖 | loading="eager" + fetchpriority="high" | 不要延遲載入主角；拉高下載優先級 |
| LCP 是 CSS 背景圖或 JS 動態插入 | <link rel="preload" as="image" fetchpriority="high"> | 瀏覽器從 HTML 掃不到，要主動宣告 |
| 內文圖、頁尾圖、側欄縮圖 | loading="lazy"（預設即可） | 不在首屏，延後載入省頻寬 |
| 全站只有 1–2 張關鍵圖 | 只對那 1–2 張用 fetchpriority="high" | 濫用高優先級會把佇列分流掉 |
Eleventy Image Transform 預設 lazy | 主視覺圖手動覆寫 loading="eager" | 管道預設 lazy ≠ 每張都該 lazy |
一句話心法：LCP 元素 不要 lazy；關鍵圖 拉高優先級；其餘圖片照常 lazy。
LCP 優化策略（核心：優先級 + 不被 lazy）
1. 不要 lazy-load LCP
最常見的壞操作：把 LCP 圖片加上 loading="lazy"。這會刻意延遲「載入 → 解碼 → 繪製」，LCP 就跟著往後延。
<!-- ❌ 自殺操作：主視覺圖被 lazy -->
<img src="/img/hero.webp" loading="lazy" alt="主視覺">
<!-- ✅ 首屏主角：明確 eager + 高優先級 -->
<img
src="/img/hero.webp"
alt="主視覺"
width="1200"
height="630"
loading="eager"
fetchpriority="high"
/>順便補 width／height 預留版面——LCP 和 CLS 常常同一張圖一起修。細節見站內 圖片最佳化與 CLS 解決方案。
2. 用 fetchpriority 把關鍵資源拉到前面
當 LCP 是圖片時，方向是：
- 主視覺圖：加
fetchpriority="high" - 配合（需要時）在
<head>用 preload 宣告，讓瀏覽器先知道「這張是主角」
<!-- CSS 背景 LCP 或較晚才出現在 DOM 的圖：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"
/>fetchpriority="high" 適用在 LCP／首圖這種關鍵資源；不要濫用，不然你會把優先權分流掉，大家都變「高優先級」就等於沒有。
3. Eleventy 靜態站：管道預設 lazy 的陷阱
若你用 @11ty/eleventy-img 的 HTML Transform，設定裡常見預設 loading: "lazy"——對內文圖很好，對 主視覺圖是災難。在該張圖覆寫：
<img
src="/img/hero.png"
alt="產品主視覺"
loading="eager"
fetchpriority="high"
sizes="(max-width: 800px) 100vw, 1200px"
/>同時確認主視覺圖檔案大小合理（目標 < 150KB）、顯示寬度對齊（手機 400px 寬就不要傳 4000px 原圖）。格式用 WebP／AVIF 通常比 JPEG 小 25–50%。
4. 避免 render-blocking 讓首屏後面卡住
如果你把非關鍵 JS／CSS 搞成阻塞鏈，LCP 再怎麼優先級也可能等不到繪製窗口。快速檢查：
| 資源類型 | 建議 |
|---|---|
| 非關鍵 JavaScript | defer 或 async；第三方標籤延後到 requestIdleCallback |
| CSS | 避免 @import 串接；關鍵 CSS < 14KB 可考慮 inline |
| Web 字體 | font-display: swap；關鍵字體可 <link rel="preload" as="font"> |
GTM 延遲載入的具體寫法，可參考站內 GTM 延遲載入：用 requestIdleCallback 降低 PSI 的 TBT。
一個快速驗收心法：先 CLS 穩，再談 LCP
LCP 是「什麼時候畫出來」，CLS 是「有沒有抖」。有些站看起來 LCP 差，其實是版面在動，最後量測也會一起變差。
建議順序：
- 先確保圖片／嵌入不會讓版面在載入期抖動（CLS 預留）
- 再回頭把 LCP 圖片的優先級拉到位
- 最後用 GSC → 體驗 → Core Web Vitals 對 欄位資料 驗收（28 天週期）
框架快速對照
| 框架 | 圖片管道 | LCP 注意事項 |
|---|---|---|
| Hugo | resources.Get + Resize／webp | 主視覺圖模板別加 lazy |
| Eleventy | @11ty/eleventy-img | Transform 預設 lazy，主視覺圖覆寫 eager + fetchpriority |
| Astro | astro:assets 或 <Image /> | 內建 lazy，記得 LCP 關 lazy |
推薦工具／資源
- PageSpeed Insights — 看 LCP 元素與子項目診斷（TTFB、資源載入延遲、元素渲染延遲）
- Google Search Console — 體驗 → Core Web Vitals，以真實使用者資料為準
- ZeroSSL — 若 LCP 慢且 TTFB 高，先確認 HTTPS 正常、憑證鏈完整；混合內容或憑證問題會拖瀏覽器行為，進而連動體驗類指標
結語：LCP 優化是「不要拖關鍵資源」的工程紀律
- 用 PSI／DevTools 找出真正的 LCP 元素，別憑感覺改
- LCP 元素 不要
loading="lazy"；關鍵圖加fetchpriority="high"，必要時 preload - Eleventy 管道預設 lazy 時，主視覺圖一定要手動覆寫
- render-blocking 別讓首屏卡住；驗收以 GSC 欄位資料為準
下一步：先把 LCP 圖片／資源優先級調到位；同時確保 HTTPS／憑證鏈完整——自架站可用 ZeroSSL 申請免費憑證，流程穩了再回 GSC 看 28 天滾動更新。改完記得再來一杯，這次是慶祝分數回來的那杯。
