如何為網站最佳化圖片：實用指南
圖片常占頁面傳輸的重要部分，也會影響發現、解碼、版面及 Largest Contentful Paint。最佳化可產生實質改善，但固定節省量或排名結果不適用每個頁面。以下流程可逐步測量。
為什麼圖片最佳化比以往更加重要
HTTP Archive 頁面重量報告顯示圖片仍是許多頁面的重要部分，儘管中位數會改變。Largest Contentful Paint (LCP) 測量視窗中最大合格內容的繪製時間；它常是圖片，但不一定。
Google 公開的 LCP 門檻把 75 百分位的 2.5 秒以下列為良好，4 秒以上列為不良。若 LCP 資源是瓶頸，圖片工作可能讓頁面跨越門檻，但本身不能保證通過 Core Web Vitals 或取得搜尋位置。
第 1 步：選擇正確的格式
格式選擇會大幅影響大小和能力。以下為定性比較，因基準結果取決於來源、編碼器、設定及品質目標：
| 格式 | 最適合 | 大小表現 | 瀏覽器支援 |
|---|---|---|---|
| JPEG | 照片、傳統相容性 | 基準 | 非常廣泛 |
| WebP | 照片 + 圖形 | 通常有效率；測試編碼器 | 目前主要瀏覽器；檢查受眾 |
| AVIF | 經測試的現代傳遞流程 | 可能很有效率；編碼成本可能較高 | 目前主要瀏覽器；可能需要備援 |
| PNG | Logo、圖示、含文字圖形 | 對部分平面圖形有效率；許多照片較大 | 非常廣泛 |
| SVG | 圖示、插圖 | 依內容而定的向量標記 | 瀏覽器廣泛支援；清理不可信 SVG |
WebP 是許多網站有用的預設候選，但不是通用答案。若流程和受眾支援 AVIF，可把它作為較前的 <source>，以 WebP 或 JPEG 備援。Vizua 可將 JPG 轉 WebP或轉 AVIF；檔案在瀏覽器處理，不會送到圖片處理伺服器。
深入比較請看WebP 與 AVIF及有損與無損壓縮說明。
第 2 步：調整至實際顯示尺寸
一張 4000 × 3000 像素照片以 800 × 600 顯示時，來源像素遠超槽位需要。高密度響應式螢幕可能需要較大候選，但傳送相機原檔通常增加不必要的傳輸和解碼。
原則是提供接近繪製尺寸及密度的候選。用 srcset 和 sizes 讓瀏覽器選擇，考慮版面寬度、裝置像素密度、品質、縮放及美術方向，而非固定一個「Retina」倍數。
可依版面調整的起始尺寸示例：
- 全寬主圖：從最大繪製槽位開始，再為相關密度和斷點產生候選
- 文章圖片：配合內容欄及較寬的響應式狀態
- 縮圖：為每個卡片尺寸產生接近的候選，不重用主圖
- 頭像：考慮顯示圓形或方形、裝置密度及詳細個人頁
壓縮前使用 Vizua 的圖片調整大小建立合適候選。節省量取決於原始和目標像素數；請測量產生的檔案。
第 3 步：以正確的品質壓縮
選格式並調整大小後，設定編碼器。品質刻度非線性，也未在編碼器或格式間標準化。較低值在有損編碼通常用更多資訊換較少位元組，但必須在實際輸出測量大小和視覺變化。
建議品質設定：
- JPEG：75–85 可作為照片的保守起始範圍。刻度不同，請檢查輸出。
- WebP：75–80 是起始範圍，不保證等同 JPEG 數值。
- AVIF：部分工具可從 60–75 開始；品質刻度和編碼行為不同。
- PNG：先試更強無損壓縮。把調色盤量化至最多 256 項可能省更多，但屬有損色彩減少，需檢查。
Vizua 的 JPEG 壓縮器可調整品質並檢查輸出。詳細方法請看不失品質的圖片壓縮。
第 4 步：高效傳輸圖片
良好的壓縮只是成功的一半。如何將圖片傳遞給瀏覽器，對效能同樣至關重要。
設定明確的尺寸
為每個 <img> 提供準確的固有 width 和 height，或用明確版面規則預留槽位。瀏覽器可提早建立比例，減少圖片相關移動；但字型、插入內容、動畫和錯誤的響應式樣式仍會影響 Cumulative Layout Shift (CLS)。
懶加載首屏以下的圖片
對充分位於初始視窗外的圖片考慮 loading="lazy"。不要機械式套在可能的 LCP 圖片或立即需要的內容。瀏覽器規則、輪播、列印、快速捲動及隱藏版面都需要測試。
優先化你的主視覺圖
不要延遲可能的 LCP 圖片。若資源真正值得初期頻寬，可考慮 fetchpriority="high"，並確保初始 HTML 可發現。不要廣泛給高優先；用追蹤及實際資料確認效果。
使用響應式圖片
srcset 和 sizes 提供候選並描述預期槽位。瀏覽器考慮視窗、密度、快取及實作。確保 sizes 符合真實版面；錯誤值可能選擇過大或過小候選。
步驟 5：定期稽核與測量
圖片最佳化不是一次性的任務。你新增的每張圖片都可能讓效能悄悄退步。
- PageSpeed Insights：在代表頁執行 PageSpeed Insights。分開查看實際與實驗室 LCP，再檢查目前圖片診斷，不依賴可能改名的稽核標籤。
- DevTools Network：按大小排序要求並在脈絡中檢查大圖。確認尺寸、格式、壓縮、快取及優先度符合角色，不套用單一 KB 上限。
- 自動化：把圖片最佳化加入建置流程，在發布前發現過大圖片
快速檢查清單
- 產生並比較合適的 JPEG、WebP、AVIF、PNG 或 SVG 變體
- 調整至實際顯示尺寸，不超過需要的寬度
- 從保守設定開始，比較位元組和視覺輸出；不要把不同格式的品質數值視為相等
-
為每個
<img>預留準確槽位，通常使用固有width和height -
為可能的 LCP 圖片考慮
fetchpriority="high"，再測量 - 延遲合適的畫面外圖片；測試捲動和版面
- 使用
srcset/sizes提供響應式圖片 - 依頁面、受眾和實際資料設定效能預算
- 移除不必要的私密中繼資料，但保留流程需要的色彩描述檔等 — 參閱 EXIF 與隱私
- 定期用 PageSpeed Insights 稽核
常見問題
網站最適合哪種圖片格式？
沒有單一最佳格式。JPEG 對照片相容性廣；WebP 支援有損、無損、透明及動畫；若流程和受眾支援，AVIF 可很有效率；PNG 適合邊緣銳利的無損圖形；SVG 適合可信的向量作品。產生代表性變體，依實測大小、品質、相容性及功能需求選擇。
未最佳化圖片會讓網站慢多少？
影響取決於頁面、視窗、網路、快取及圖片角色。過大的 LCP 圖片可能增加大量傳輸和解碼時間，但沒有一個檔案大小對應固定 LCP。用實際 Core Web Vitals 和實驗室追蹤，判斷傳輸、發現、優先度、解碼或繪製何者是瓶頸。
所有圖片都應延遲載入嗎？
不應。當延後有幫助時，延遲最初在視窗外的圖片，但不要延遲可能的 LCP 圖片。高抓取優先只給真正重要的初始圖片；濫用提示會降低效用。請測試，因為版面、預載發現及響應式來源選擇也影響時間。
每張圖片都需要指定寬高嗎？
HTML img 應在可能時提供正確的固有寬高，讓瀏覽器在下載前推算比例。明確尺寸的 CSS 容器或 aspect-ratio 規則也可預留空間。關鍵是穩定且準確的槽位；錯誤尺寸或後期版面變動仍會造成 Cumulative Layout Shift。
圖片最佳化如何影響 SEO？
當圖片是瓶頸時，可改善體驗和 Core Web Vitals。Google 在更廣的排名系統中使用頁面體驗訊號，但較小圖片不保證排名上升。請為使用者最佳化，驗證實際資料，並兼顧內容品質、相關性、可檢索性及其他 SEO 因素。