網站圖片優化實驗：從 LCP 4.2 秒壓到 1.8 秒的完整 SOP

實驗開場：我拿了一個 Next.js 專案，把首頁圖片的 LCP 從 4.2s 壓到 1.8s

這不是一篇「圖片為什麼重要」的原理文。這是一份以解決首屏 LCP 圖片載入慢為核心的圖片優化實驗流程 SOP，基於 LCP 的完整優化方法 原則執行。目標很明確：把首頁那張 hero image 的 LCP（Largest Contentful Paint）從 4.2 秒，壓到 1.8 秒以下。我將完整記錄每一步的診斷、操作、以及帶來的數據變化，讓你也能按圖索驥，解決自己網站上最棘手的圖片載入瓶頸。

整份流程的核心邏輯很簡單：先找到瓶頸（診斷），再依序施加干預（優先級、格式、載入策略、響應式），每一步都以 LCP 數值作為驗證標準。下面就是完整的實驗路徑。

步驟一：診斷，確認你的 LCP 元素到底是誰

優化不是瞎猜。我首先用 Chrome DevTools 的 Performance 面板錄了一次頁面載入，在「Timings」區塊的「Largest Contentful Paint」事件上，清楚看到對應的 DOM 元素是首頁的 banner 圖片。根據 LCP 元素識別 指南，這是最準確的確認方式。在 Chrome DevTools Performance 面板 中，點擊 LCP 事件後右側會直接標示出該元素的 DOM 節點，省去你對照元素的時間。

在我的案例裡，它是一張 1200px 寬、原始體積 280KB 的 JPG 格式橫幅。這一步確認了，所有優化工作都將圍繞這張圖展開。

步驟二：優先級重置，用 fetchpriority='high' 跟瀏覽器搶資源

瀏覽器預設把所有圖片視為同等重要，這導致關鍵的 LCP 圖片在網路佇列（Network Queue）中排在 JavaScript 和 CSS 之後。我在該圖片的 `` 標籤上加入了 `fetchpriority="high"` 屬性，明確告訴瀏覽器提升其載入優先級。

根據 fetchpriority LCP 圖片 的實測，這單行改動的效果立竿見影：改動前 LCP 4.2s，加上 fetchpriority 後，LCP 降至 3.5s。這省下的 0.7 秒，完全來自網路資源分配順序的改善。

這一步的本質是「不改動圖片本身，只改動瀏覽器對它的態度」。成本幾乎為零，收益卻很穩定。

步驟三：格式革命，AVIF 替代 JPEG 砍半下載體積

我選擇以 AVIF 作為主力格式，並保留 WebP 作為不支援 AVIF 的瀏覽器的 fallback。直接替換格式後，下載體積從 280KB 砍到 128KB，LCP 從 3.5s 降至 2.8s。這 0.7 秒的改善，來自純粹的「更小的檔案、更快的傳輸」。

步驟四：移除誤殺，你的 LCP 圖片可能正被 lazy loading 拖慢

我檢查原始 HTML，發現一個常見錯誤：這張首屏的 hero image 竟然也帶有 `loading="lazy"` 屬性。這等於在命令瀏覽器延遲載入最重要的內容——它必須等到 JavaScript 執行完畢後才會開始下載圖片，白白浪費了數百毫秒。

我移除了 hero image 上的 `loading="lazy"`，並確保其他首屏以下的圖片正確使用該屬性（那些圖片用 lazy loading 是合理的）。此操作後，LCP 從 2.8s 顯著降至 2.2s。這一步提醒我們：優化不是「越多屬性越好」，而是要讓每個屬性出現在正確的元素上。

步驟五：響應式收尾，srcset 確保不同裝置載入正確尺寸

在桌面端優化接近尾聲時，我注意到手機端的 LCP 數值（3.1s）仍高於桌面端。這是因為手機一直在下載為桌面設計的 1200px 寬圖片——一個 320px 視口的手機根本不需要那麼大的圖。

我為該圖片生成了 600px、960px 和 1200px 三個寬度的 AVIF 和 WebP 版本，並使用 `` 與 `srcset`、`sizes` 屬性，讓瀏覽器根據視口和設備像素比自動選擇最合適的版本。這步驟主要改善了手機體驗，將手機端的 LCP 從 3.1s 壓到了 1.8s，達到了我們的優化目標。關於行動端的效能瓶頸，可參考 行動裝置 LCP 優化 的完整指南。

實驗結論：總結數據與可複製的代碼清單

本次優化實驗的完整數據路徑清晰可循：

這證明了圖片優化是一個可累積、數據驅動的過程。以下是我整合了所有優化步驟後的最終 HTML `` 區塊代碼，它包含了格式降級、優先級設定、尺寸聲明和響應式處理，你可以直接複製並替換其中的 URL 和參數。

下一步：自動化與持續監控

手動轉圖和調整參數只適合實驗驗證。為了讓這種優化成為團隊的常態，我將上述的格式轉換（AVIF/WebP）、多尺寸生成、以及 EXIF 資料移除，整合進一個基於 Node.js 和 sharp 函式庫的腳本。透過 CI/CD 管線，每次推送新圖片時自動執行壓縮。

而優化是否退步，則持續監控 CrUX 數據 中的真實用戶 LCP 指標，並搭配 Web Vitals Chrome Extension 在開發環境即時反饋，形成一個完整的效能優化閉環。這份 SOP 的終極目標不是一次性地把 LCP 壓下來，而是讓圖片優化變成一個可重複、可監控、可自動化的流程。

加上 fetchpriority="high" 但 Lighthouse 分數沒變，可能原因？

首先確認 Lighthouse 測量的環境（模擬網路、設備）是否與你開發時不同。其次，檢查瓶頸是否在 TTFB（伺服器回應時間），若伺服器回應本身就慢，圖片優先級再高也無法彌補。最後，確認是否有其他渲染阻塞資源（如大型 CSS 或同步 JavaScript）延遲了 LCP 的觸發時機，這需要單獨處理。詳見 TTFB 優化。

用 AVIF 後，在舊版 Safari 或其他瀏覽器圖片顯示不出來怎麼辦？

這正是 `` 元素和 `` 標籤存在的意義。在代碼範例中，AVIF 的 `` 放在最前面，WebP 的 `` 緊隨其後，最後的 `` 作為所有不支援前兩者的瀏覽器的兜底。瀏覽器會從上到下選擇它支援的第一個格式，確保所有用戶都能看到圖片。

優化後 CLS（Cumulative Layout Shift）反而增加了，是什麼原因？

一個常見原因是移除了原始 `` 標籤的 `width` 和 `height` 屬性，或者在 CSS 中強行覆蓋了它們。瀏覽器需要這些 HTML 屬性來在圖片下載前計算並預留空間。確保你的 `` 標籤上寫明了正確的 width 和 height，並搭配 CSS 的 `height: auto`。具體原理和修復方法請參閱 CLS 圖片修復指南。

除了圖片，還有什麼 Core Web Vitals 環節需要一起優化？

圖片通常是最大的視覺內容，但 LCP 也受 TTFB 和渲染阻塞資源影響。同時，CLS 和 INP（Interaction to Next Paint）是另外兩個核心指標。建議參閱 Core Web Vitals 整體指南，對網站進行全面的體檢，找出所有需要優化的瓶頸，而不是只關注單一指標。

圖片 EXIF 資料必須移除嗎？有什麼影響？

建議移除。EXIF 資料包含相機設定、拍攝時間、甚至 GPS 座標等資訊，這些資訊對網頁顯示毫無用處，卻會佔用幾 KB 到數十 KB 的體積。在自動化壓縮腳本中加入 EXIF 移除步驟（如 sharp 的 `.withMetadata(false)` 或 ImageMagick 的 `-strip`），可以進一步減少傳輸體積，且不會有任何副作用。