AVIF、WebP、JPEG XL 該用哪一個？2026 網頁圖片格式完整選擇指南：瀏覽器支援現況、壓縮率實測數字、picture 寫法與轉檔指令（含 Hugo／sharp 實作）

一句話結論：2026 年 10 月的網站圖片預設值應該是「AVIF 為主、WebP 或 JPEG 當 fallback」，因為 AVIF 在同品質下幾乎總是最小、全球支援率約 96%；JPEG XL 在 10 月 6 日與 13 日分別於 Chrome 155、Firefox 158 預設啟用後終於三引擎到齊，但它真正的價值在無損、漸進式載入與 JPEG 無損重封裝，不是「全面取代 AVIF」。

為什麼現在該重看一次這個題目

圖片通常是一個網站裡最重的資源。在 Core Web Vitals 的 LCP（最大內容繪製）指標裡，主視覺圖片往往是決定分數的那一個元素；以一張 1200px 的照片來說，同樣的視覺品質下，格式換對了可能直接少掉一半以上的位元組——這比大多數前端優化手段都划算。

但這個題目在 2026 年 10 月剛好遇到兩件事同時發生：

1. Chrome 155（2026-10-06 發布）預設啟用 JPEG XL 解碼，使用 Google Research 以 Rust 寫的 jxl-rs 解碼器，Windows／macOS／Linux／ChromeOS／Android 全都開。
2. Firefox 158（2026-10-13 發布）預設啟用 JPEG XL，並把 image/jxl 加進 HTTP Accept 標頭。

也就是說，過去四年「AVIF 有支援、JPEG XL 只有 Safari」的舊結論已經過期。舊文章、甚至 AI 產出的比較表，很可能還在告訴你「JPEG XL 沒有任何瀏覽器支援」——這個說法從 2026 年 10 月起就是錯的。

一表看懂：四種格式的核心差異

覆蓋率數字取自 caniuse 的 usage_perc_y（AVIF／WebP 為完整支援比例），JPEG XL 的覆蓋率是 Chrome 155、Firefox 158 剛預設啟用後的過渡期數字，會隨著使用者更新而快速上升。

瀏覽器支援現況（逐版本）

一個常被忽略的細節：JPEG XL 的支援是「部分支援」而不是「完全支援」的 Safari 版本佔了大量流量。Safari 17 從 2023 年就支援 JXL 靜態圖，但 Mozilla 一路強調 Safari 的實作缺了漸進式渲染等關鍵功能。所以「三引擎到齊」不等於「功能對等」。

壓縮率：誰在什麼情境贏（附具體數字）

這部分的數字來源必須講清楚，因為網路上（包括 AI 生成的答案）充滿互相複製的錯誤數字。以下是兩份可信度較高的實測：

• Jake Archibald（2026-10-15，image-codec-bench 腳本，M4 Pro 跑 7 張測試圖）：同為 SSIMULACRA2 品質分數 70 的照片，AVIF 41.4 kB、libjxl 58.4 kB（+41%）、jixel 46.6 kB（+12%）。結論是有損照片上 AVIF 幾乎總是最小：JPEG XL 在預設 effort 下通常大 15–25%，開到最大 effort 仍大 6–20%，但也有 JPEG XL 反超的例外（例如「weasel」那張）。
• 多來源彙整（Cloudinary、Netflix、獨立站點實測）：以視覺品質 80 為基準，WebP 比 JPEG 小約 31%、AVIF 比 JPEG 小約 54%、AVIF 又比 WebP 小約 33%（不同測試集的區間大致落在 WebP 25–39%、AVIF 37–67%）。

依內容型態分開看更實用：

速度與資源：AVIF 的代價

壓縮率只是半張帳單，另一半是「你要花多少算力換」。

三個實務結論：

1. AVIF 不要在使用者上傳的路徑上即時編。放到背景佇列或 build 階段；批次處理時用 --speed 6～8（avifenc 的數字越小越慢越好）取平衡。
2. AVIF 的 effort 值得開高（s5 約多花 3 倍時間換 10% 檔案縮減），libjxl 的 effort 不值得開到頂（e10 只比預設好一點點，卻慢約 18 倍）；jixel 的 slow 值得，extraslow 邊際效益低。
3. 4:2:0 不要當預設。AVIF 的 4:2:0（色彩解析度減半）通常不會讓檔案明顯變小，反而更難達到高品質；沒時間逐一比較時就用 4:4:4。

場景決策表：直接照這個選

實作一：<picture> fallback 的正確寫法

<picture>
  <source type="image/avif" srcset="photo-800.avif 800w, photo-1600.avif 1600w" sizes="(max-width: 800px) 100vw, 800px">
  <source type="image/webp" srcset="photo-800.webp 800w, photo-1600.webp 1600w" sizes="(max-width: 800px) 100vw, 800px">
  <img src="photo-800.jpg"
       width="800" height="600"
       loading="lazy" decoding="async"
       alt="說明文字">
</picture>

三個一定要記住的點：

• width 與 height 絕對不能省。瀏覽器需要它們預留版面空間，否則圖片載入時版面會跳動（CLS）。
• 瀏覽器是用 type 屬性判斷支援度，不是先下載再檢查——所以順序要「新到舊」，把相容性最好的放進 <img>。
• 不要只放 JPEG XL。Edge、舊版 Chrome／Firefox、email、聊天軟體預覽都還不支援；<img src="x.jxl"> 在那些環境就是破圖。若要用 JXL，就把它放在 <picture> 的第一個 <source>：

<picture>
  <source type="image/jxl" srcset="photo.jxl">
  <source type="image/avif" srcset="photo.avif">
  <source type="image/webp" srcset="photo.webp">
  <img src="photo.jpg" width="1600" height="900" alt="說明文字">
</picture>

實作二：轉檔指令（終端機）

以下指令為各工具官方 CLI 的常見用法；參數在不同版本間會調整，執行前先跑一次 --help 最保險。

# 1) AVIF：速度 6、品質約 60、alpha 無損
avifenc --speed 6 --qcolor 60 --qalpha 100 input.png output.avif
# 批次轉整個資料夾（GNU parallel 範例）
ls *.png | parallel avifenc --speed 6 --qcolor 60 {} {.}.avif

# 2) WebP：品質 80、最高壓縮努力
cwebp -q 80 -m 6 -mt input.jpg -o output.webp

# 3) JPEG XL：有損，distance 1.0（近似視覺無損）、effort 7
cjxl input.png output.jxl -d 1.0 -e 7

# 4) JPEG XL 無損重封裝既有 JPEG（縮小、可還原）
cjxl photo.jpg photo.jxl -d 0 --lossless_jpeg=1
djxl photo.jxl restored.jpg          # 還原回原 JPEG

# 5) 若想保留原檔大小對照
for f in *.jpg; do
  cwebp -q 80 -m 6 "$f" -o "${f%.jpg}.webp"
  avifenc --speed 6 --qcolor 60 "$f" "${f%.jpg}.avif"
  cjxl "$f" "${f%.jpg}.jxl" -d 1.0 -e 7
  ls -l "$f" "${f%.jpg}.webp" "${f%.jpg}.avif" "${f%.jpg}.jxl" | awk '{print $5, $9}'
done

Node 專案裡最省事的是 sharp（底層用 libvips，AVIF／WebP 都有）：

import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600, withoutEnlargement: true })
  .avif({ quality: 60, effort: 4 })   // effort 0-9，數字越大越慢越小
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

實作三：Hugo 站台（avif 內建可輸出，jxl 不行）

Hugo 的內建圖片處理可以輸出 avif、bmp、gif、jpeg、png、tiff、webp——清單裡沒有 JPEG XL，這是選型時要先知道的硬限制（本站在 Hugo 上，所以 JXL 若要上線得多一條外部管線）。

先在 hugo.toml 調參數（以下為可用的設定鍵，數值依官方預設）：

[imaging]
  anchor = 'smart'
  bgColor = 'ffffff'
  [imaging.avif]
    compression = 'lossy'   # 或 lossless
    encoderSpeed = 10       # 數字越大越快、檔案越大
    hint = 'photo'          # drawing / icon / photo / picture / text
    quality = 60
  [imaging.webp]
    compression = 'lossy'
    hint = 'photo'
    method = 2
    quality = 75

樣板裡用 Process 一次產出兩種格式並組出 <picture>：

{{ $src := .Resources.Get "hero.jpg" }}
{{ with $src }}
  {{ $avif := .Process "resize 1600x q60 avif" }}
  {{ $webp := .Process "resize 1600x q75 webp" }}
  <picture>
    <source srcset="{{ $avif.RelPermalink }}" type="image/avif">
    <source srcset="{{ $webp.RelPermalink }}" type="image/webp">
    <img src="{{ .RelPermalink }}" width="{{ .Width }}" height="{{ .Height }}" alt="">
  </picture>
{{ end }}

幾個 Hugo 特有的注意事項：

• 處理後的結果會快取在 resources/_gen，每次改 Process 參數都會重編；換參數或刪圖後可以跑 hugo --gc 清掉孤兒檔（本站的 build 指令本來就帶 --gc）。
• 部署到 CI（Netlify／GitHub Actions）時，要把 Hugo 的 image cache 一起快取，否則每次 build 都重新編碼一次 AVIF，build 時間會暴增。
• 大圖先縮再處理：一張 4032×2268 的原圖，處理時吃的記憶體與時間遠高於 1920×1080。

常見迷思與陷阱

本文沒有做的事（查證保留）

• 沒有用本站自己的圖片重跑 benchmark。文中的壓縮率與速度數字來自 Jake Archibald 的公開測試腳本與測試圖集（M4 Pro、單執行緒計時）以及 Cloudinary／Netflix 等來源的公開數據；不同圖集、不同硬體、不同 encoder 版本都會得到不同百分比。
• 沒有實測 Edge／Samsung Internet／email 客戶端的 JPEG XL 行為，其「尚未支援」是依 caniuse 與瀏覽器廠商說明判定。
• caniuse 覆蓋率是 2026-10-16 當日快照，JPEG XL 的數字（約 17%）會隨使用者更新快速變動。
• 指令範例以官方 CLI 的常見用法撰寫，未逐一在本機對所有版本驗證；請以 avifenc --help、cwebp -longhelp、cjxl --help 的當下輸出為準。
• 沒有評估各家 CDN／平台的自動圖片轉換服務（如 Cloudflare Images、WordPress、Shopify 的支援狀況因方案而異），這部分建議以平台當下文件為準。

站內延伸閱讀

• Hugo 靜態網站生成器：重塑網頁創建的未來
• GitHub Actions 完整教學 2026：從 YAML 語法、Matrix 矩陣到 Hugo 自動部署
• Penpot 完整教學 2026：開源 Figma 替代品 Docker 自架，Design Tokens 到 CSS Grid
• 2026 年 SEO 怎麼做？用 Semrush MCP + ChatGPT 完成網站稽核與 AI 搜尋曝光優化

資料來源與查證方式

• Jake Archibald，〈JPEG XL vs AVIF for web use-cases〉，2026-10-15（一手 benchmark：jakearchibald.com/2026/jpeg-xl-vs-avif，測試腳本 github.com/jakearchibald/image-codec-bench）
• Chrome for Developers 公告〈Shipping JPEG XL in Chrome〉與 Chrome 155 版本說明（2026-10-06）；Mozilla Hacks〈Intent to Ship: JPEG XL〉（2026-08-24）與 Firefox 158 發布說明（2026-10-13）
• MDN〈Image file type and format guide〉（格式能力與相容性）、web.dev〈Image formats: AVIF〉
• caniuse.com 功能資料（avif／webp／jpegxl）於 2026-10-16 以官方 GitHub 資料檔抓取：AVIF 完整支援 96.33%、WebP 97.08%、JPEG XL 約 17%
• Hugo 官方文件：〈Image processing〉、〈Process〉、〈Configure imaging〉（2026-10-16 查證；可輸出格式清單為 avif／bmp／gif／jpeg／png／tiff／webp）
• 比較與壓縮率數字另以 NotebookLM deep research（44 個來源）交叉比對 Cloudinary、Netflix、獨立站點實測數據，並標註來源差異