如何最佳化網站圖片:2026 年完整指南
圖片佔平均網頁總重量的約 40%。將它們正確最佳化,你可以讓頁面大小減半、讓最大內容繪製(LCP)控制在 2.5 秒以下,並在搜尋結果中排名更高。以下是完整的步驟流程。
為什麼圖片最佳化比以往更加重要
根據 HTTP Archive 資料,行動裝置網頁的中位數重量現在約為 2.5 MB,其中圖片就佔了約 1 MB。Google 的 Core Web Vitals——尤其是最大內容繪製(LCP)——直接衡量你最大可見元素的載入速度。在大多數頁面上,那個元素就是圖片。
LCP 低於 2.5 秒為「良好」;超過 4 秒為「差」。以圖片為 LCP 元素的頁面,其 75 百分位的載入時間幾乎是以文字為 LCP 的頁面的兩倍。一張最佳化精良的主視覺圖與一張臃腫的圖片之間,往往就是 Core Web Vitals 綠燈與紅燈的差距。
第 1 步:選擇正確的格式
格式選擇對檔案大小的影響最為單一且關鍵。以下是主要網頁格式依真實壓縮基準的比較:
| 格式 | 最適合 | 相對 JPEG 大小 | 瀏覽器支援 |
|---|---|---|---|
| JPEG | 照片、傳統相容性 | 基準 | 100% |
| WebP | 照片 + 圖形 | 小 25–35% | 97% 以上 |
| AVIF | 效能要求高的網站 | 小約 50% | 約 95% |
| PNG | Logo、圖示、含文字圖形 | 通常更大 | 100% |
| SVG | 圖示、插圖 | 極小(向量) | 100% |
對大多數網站而言,WebP 是最安全的預設選擇——它同時適合照片和圖形,壓縮率高,且幾乎所有瀏覽器都支援。若你的環境支援,可以使用 <picture> 元素優先提供 AVIF,以 WebP 作為備援。你可以在 Vizua 中將 JPG 轉換為 WebP 或轉換為 AVIF——一切在瀏覽器中完成,無需上傳。
想要更深入的比較?請參考我們的WebP vs AVIF 分析和有損 vs 無損壓縮說明。
第 2 步:調整至實際顯示尺寸
一張 4000 × 3000 像素的相機照片,在你的網站上以 800 × 600 顯示,浪費了約 80% 的像素。那些不可見的像素仍然消耗頻寬和解析時間。
原則是:以接近或等於實際渲染尺寸的圖片提供。標準顯示器上,精確匹配像素尺寸。2x Retina 螢幕上,提供兩倍顯示寬度的圖片以確保銳利——但不要超過此尺寸。
實用目標尺寸:
- 全版主視覺圖:1600–1920 px 寬(Retina 最多 2 倍)
- 部落格內文圖:800–1200 px 寬
- 縮圖:300–400 px 寬
- 頭像:64–128 px(2x 最多 256 px)
使用 Vizua 的圖片調整工具,在壓縮前先將圖片縮放到所需寬度。光是調整尺寸,就能縮減 70–90% 的檔案大小。
第 3 步:以正確的品質壓縮
選好格式、調整尺寸後,壓縮是榨取剩餘節省空間的最後步驟。品質滑桿的影響比多數人意識到的更大——品質與檔案大小的關係並非線性。將 JPEG 品質從 100 降到 80 能省下大量空間;從 80 降到 60 的邊際效益遞減,且偽影開始顯現。
建議品質設定:
- JPEG:75–85——照片的最佳甜蜜點。品質 80 的 JPEG 通常比未壓縮原始檔小 60–80%,且無可見差異。
- WebP:75–80——視覺品質相當於 JPEG 85,但檔案更小。
- AVIF:60–75——即使較低的數值,因編解碼器的效率而仍呈現出色效果。
- PNG:使用最大壓縮級別(無損)。若圖形允許,可進一步縮減至 8 位元(256 色)以獲得更多節省。
Vizua 的JPEG 壓縮器使用最佳化演算法自動處理,能在邊緣和漸層最敏感的區域保留更多細節。詳細的逐格式分析,請參考我們的無品質損失壓縮指南。
第 4 步:高效傳輸圖片
良好的壓縮只是成功的一半。如何將圖片傳遞給瀏覽器,對效能同樣至關重要。
設定明確的尺寸
在所有 <img> 標籤上都加上 width 和 height 屬性(或使用 CSS aspect-ratio)。這能防止版面位移——圖片載入時內容四處跳動的問題——直接影響你的累積版面位移(CLS)分數。
懶加載首屏以下的圖片
對頁面初始載入時不可見的圖片加上 loading="lazy"。瀏覽器會延遲下載,直到使用者捲動靠近該圖片,從而節省初始載入的頻寬。
優先化你的主視覺圖
對最重要的首屏圖片做相反的設定:加上 fetchpriority="high",並確保它沒有設定 loading="lazy"。Google 自己的測試顯示,預先載入 LCP 圖片能達到接近完美的效能分數(75 百分位 364ms),而懶加載 LCP 圖片則幾乎慢兩倍(720ms)。
使用響應式圖片
srcset 和 sizes 屬性讓瀏覽器根據使用者的螢幕大小和解析度選擇最合適的圖片版本,也可以搭配 <picture> 元素提供 AVIF + WebP + JPEG 的多格式備援:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" width="1920" height="1080" alt="..." fetchpriority="high">
</picture> 第 5 步:稽核和量測
圖片最佳化不是一次性的任務。你新增的每張圖片都可能讓效能悄悄退步。
- PageSpeed Insights:在你的關鍵頁面上執行 Google 的 PageSpeed Insights。查看 LCP 分數,以及「以新世代格式提供圖片」或「正確調整圖片大小」等建議。
- 瀏覽器 DevTools Network 分析:在 Chrome 的網路面板按大小排序,任何超過 200 KB 的圖片都值得考慮是否能調整尺寸、重新壓縮或轉換為更好的格式。
- 自動化:將圖片最佳化納入你的建置流程,在上線前就攔截過大的圖片。
快速檢查清單
- 以 WebP 或 AVIF 作為預設格式
- 調整圖片至實際顯示尺寸(不超過必要寬度)
- 壓縮:JPEG/WebP 品質 75–85,AVIF 品質 60–75
- 每個
<img>都設定width和height - 主視覺圖加上
fetchpriority="high" - 首屏以下圖片加上
loading="lazy" - 使用
srcset/sizes提供響應式圖片 - 主視覺圖控制在 200 KB 以下,縮圖 80 KB 以下
- 移除不必要的後設資料(EXIF、ICC 設定檔)——參考我們的EXIF 隱私指南
- 定期用 PageSpeed Insights 稽核
常見問題
網站最佳的圖片格式是什麼?
WebP 是 2026 年最安全的預設選擇。它產生比 JPEG 小 25–35% 的檔案,支援透明度,且在超過 97% 的瀏覽器中運作。若想要最大壓縮率,AVIF 在 2026 年瀏覽器支援率已達約 95%,可以再節省約 50%。Logo 和圖示則使用 SVG。
未最佳化的圖片會讓網站慢多少?
根據 HTTP Archive 資料,圖片佔網頁總重量的約 40%(中位數 2.5 MB 中約 1 MB 是圖片)。單一未最佳化的主視覺圖片就可能讓 LCP 超過 4 秒,Google 將這評為「差」等級,直接影響搜尋排名。
應該對所有圖片使用延遲載入嗎?
不是。只對首屏以下的圖片使用 loading="lazy"。主視覺圖(hero image)或 LCP 元素絕對不要設定延遲載入——這樣做反而會增加延遲,損害 LCP 分數。對最重要的首屏圖片,改用 fetchpriority="high"。
每張圖片都需要設定 width 和 height 屬性嗎?
是的。設定明確的 width 和 height 屬性(或使用 CSS aspect-ratio),讓瀏覽器在圖片載入前就預留正確的空間。若未設定,圖片出現時內容會四處跳動,增加累積版面位移(CLS)分數,這是 Google Core Web Vitals 的另一個重要指標。