圖片最佳化的核心是在縮小檔案體積的同時保持視覺品質。基本流程為：調整到實際顯示尺寸、以 75-85% 品質進行壓縮、轉換為 WebP 或 AVIF 格式、新增延遲載入、以及設定明確的 width/height 屬性。一項 DebugBear 案例研究 使用這套流程實現了 97.5% 的體積縮減（4.3 MB → 109 KB）。
為什麼圖片最佳化如此重要
圖片約佔網頁總體積的 64%（Sanity）。未經最佳化的圖片會直接影響：
| 指標 | 影響 | 原因 |
|---|---|---|
| LCP（最大內容繪製） | 超過 2.5 秒閾值 | 首屏大圖體積過大 |
| CLS（累積版面位移） | 內容在載入時跳動 | 缺少 width/height 屬性 |
| 跳出率 | 訪客在內容載入前離開 | 首次繪製速度慢 |
| 行動裝置排名 | 搜尋排名下降 | 在多變網路環境下頻寬消耗過大 |
三大支柱：調整尺寸、壓縮、格式選擇
支柱一：調整尺寸——收益最大的單項最佳化
按實際顯示尺寸提供圖片是最大的最佳化。根據 DebugBear 的案例，一張 7108×4744 的照片實際只以 1266×845 顯示：僅調整尺寸就將檔案從 4.3 MB 降至 495 KB（縮減 89%）。
操作步驟：
- 確定顯示尺寸——WordPress.com 建議以上傳寬度為內容區域的 1.5-2 倍為佳，可獲得清晰效果。
- 在上傳前調整尺寸——可使用預覽程式（Mac）、小畫家（Windows）或 GIMP。
- 使用
srcset和sizes屬性新增響應式圖片，根據視埠大小提供不同寬度（400w、800w、1600w）的版本。
這樣瀏覽器可以為每個視埠選擇合適的檔案——行動裝置使用者下載更小的檔案，桌面端使用者獲得清晰的版本。
支柱二：壓縮——有損 vs 無損
| 模式 | 運作原理 | 檔案大小 | 適用場景 |
|---|---|---|---|
| 有損 | 永久移除部分資料 | 更小（縮減 40-60%） | 相片、複雜影像 |
| 無損 | 精確保留所有資料 | 較大 | Logo、文字、螢幕截圖、透明圖 |
對於大多數網頁圖片，以 75-85% 品質進行有損壓縮是最佳平衡。WebP 和 AVIF 都支援這兩種模式。
支柱三：格式選擇——WebP vs AVIF vs JPEG
| 格式 | 與 JPEG 對比壓縮率 | 編碼速度 | 瀏覽器支援率（2026） | 適用場景 |
|---|---|---|---|---|
| WebP | 小 25-35% | 快 | 97%+ | LCP 圖片、通用場景 |
| AVIF | 約小 50% | 比 WebP 慢 50% | 92%+ | 極限壓縮 |
| JPEG | 基準 | 最快 | 100% | 通用備用格式 |
決策框架：
| 場景 | 推薦格式 |
|---|---|
| LCP/首屏主圖 | WebP（編碼更快、支援更廣） |
| 整體頁面體積縮減 | AVIF（壓縮率更高） |
| 產品攝影（HDR） | AVIF（廣色域） |
| 使用者上傳內容 | WebP（處理更快） |
| 動畫圖形 | WebP（支援動畫） |
| 含文字/銳利線條的圖形 | WebP 無損 |
混合方案（推薦）：參考 Framer 的做法，首次請求時提供 WebP，背景非同步轉換為 AVIF，後續訪問時提供 AVIF。這樣可以兼顧快速初始交付和更小的快取檔案。
延遲載入與響應式圖片
延遲載入會延後載入螢幕外的圖片，直到需要時才載入，從而節省頻寬並加快首屏載入。為所有首屏以下的圖片新增 loading="lazy" 屬性即可。
規則：
- 不要延遲載入首屏圖片——這會延遲 LCP。
- 使用
fetchpriority="high"提升 LCP 圖片的優先級。 -
在
<head>中使用rel="preload" as="image" fetchpriority="high"預先載入關鍵 CSS 背景圖片。 -
始終為圖片元素設定明確的 width 和 height 屬性，以防止 CLS。
工具對比
| 工具 | 適用場景 | 格式 | 批次處理 | 費用 |
|---|---|---|---|---|
| Squoosh | 開發者格式對比 | WebP、AVIF、JPEG、PNG | 支援 | 免費 |
| TinyPNG | 設計師單圖最佳化 | WebP、JPEG、PNG | 20 張 | 免費 |
| ImageLean | 注重隱私的瀏覽器端壓縮 | WebP、AVIF、JPEG、PNG | 支援 | 免費 |
| Smush | WordPress 站長 | WebP、AVIF、JPEG、PNG | 批次 | 免費/專業版 |
| Cloudflare Images | CDN 全球分發與縮放 | 自動轉換 | 即時處理 | 按量計費 |
| Next.js Image | React/Next.js 專案 | 自動 WebP/AVIF | 自動 | 免費 |
CDN 與外掛最佳化對比
| 方案 | 運作原理 | 優點 | 缺點 |
|---|---|---|---|
| CDN 方案（Cloudflare、Fastly） | 在網路邊緣最佳化並快取結果 | 零手動操作、自適應裝置 | 需要 CDN 訂閱 |
| 外掛方案（Smush、TinyPNG） | 上傳時或透過 API 處理 | 對輸出結果有更多控制 | 已有圖片需執行批次處理 |
最佳實踐：混合方案——CDN 負責即時交付，外掛負責上傳壓縮。CDN 可將國際訪客的圖片載入時間縮短 50% 以上（DebugBear）。
自動化工作流程
CI/CD 管線
GitHub Actions 可以在每次推送時使用 Squoosh CLI 或 sharp 自動壓縮和轉換格式。程式碼庫中的所有圖片在部署前都會被最佳化。
無頭 CMS
Sanity 等平台支援即時轉換來提供最佳化圖片——只需儲存一張高品質來源圖，即可自動取得縮圖、響應式尺寸和現代格式。
電子商務
- WooCommerce：Smush 直接整合——上傳時自動壓縮、批次最佳化圖片庫、CDN 全球分發。
- Shopify：內建管線處理最佳化。確保上傳的來源圖尺寸正確，且主題產生了正確的
srcset屬性。
修復 PageSpeed Insights 警告
| 警告 | 原因 | 修復方法 |
|---|---|---|
| “正確調整圖片尺寸” | 圖片大於顯示尺寸 | 調整到匹配容器尺寸 + 使用 srcset |
| “使用下一代格式提供圖片” | 使用 JPEG/PNG 而非 WebP/AVIF | 使用 Squoosh 或 Smush 自動轉換 |
| “延遲載入螢幕外圖片” | 所有圖片立即載入 | 僅為首屏以下圖片新增 loading="lazy" |
| “消除阻塞渲染的資源” | CSS/HTML 中有大段 Base64 編碼圖片 | 作為獨立檔案提供；避免對超過幾百位元組的內容使用 Base64 |
總結
按順序最佳化圖片：調整尺寸 → 壓縮 → 轉換為現代格式 → 新增延遲載入 → 設定明確尺寸。使用 CDN/外掛混合方案實現自動化。從使用 DebugBear 稽核網站開始——案例研究中的 97.5% 體積縮減，大多數網站透過這些技術都能實現。
常見問題
有損壓縮和無損壓縮有什麼區別？
有損壓縮會永久移除資料以獲得更小的檔案——適用於相片。無損壓縮精確保留所有資料——適用於 Logo、文字和螢幕截圖。WebP 和 AVIF 都支援兩種模式。對於網頁圖片，75-85% 品質的有損壓縮是業界標準。
2026 年應該使用 WebP 還是 AVIF？
LCP/首屏圖片使用 WebP（編碼更快、支援更廣）。追求極限壓縮時使用 AVIF（檔案更小、編碼更慢）。推薦混合方案：首次載入使用 WebP，快取後的後續訪問使用 AVIF。
如何修復 PageSpeed 中「正確調整圖片尺寸」和「下一代格式」的警告？
將圖片調整為匹配其顯示尺寸。將 JPEG/PNG 轉換為 WebP 或 AVIF。使用 srcset 配合 <picture> 元素，根據螢幕尺寸和格式支援提供合適的版本。WordPress 使用者可以透過 Smush 外掛實現自動化。
發佈留言