2026 WebP vs AVIF vs JPEG XL 三大格式完整比較：技術原理與實戰選擇指南
從技術實現來看：為什麼我們需要新格式
JPEG 誕生於 1992 年，PNG 誕生於 1996 年。這兩個格式服役超過 30 年，面對現代網頁的需求（高解析度螢幕、行動網路頻寬、Core Web Vitals 效能指標），壓縮效率已經明顯不足。
WebP、AVIF、JPEG XL 是目前最有潛力取代 JPEG/PNG 的三種新世代格式。它們各自基於不同的技術架構，在壓縮效率、功能特性和生態系支援上有顯著差異。想先掌握 JPEG、WebP、AVIF 的底層演算法脈絡，可以先看 圖片壓縮演算法 5 代演進。這篇從底層原理開始，逐項分析它們的技術差異與實際表現。
實測下來我最常被問的一句是：「所以到底要用哪個？」——說穿了沒有單一答案。我在 lpic.cc 跑過一個 3,200 張圖的 benchmark（涵蓋照片、UI 截圖、插畫三類素材），WebP 平均比 JPEG 小 28%、AVIF 再小 42%、JPEG XL 在無損模式下小 55%。但這些數字換到編碼時間就完全翻轉：WebP 0.3 秒、AVIF 2.8 秒、JPEG XL 1.6 秒。這個坑很多團隊第一次導入才發現——壓縮率好的格式，server 端成本會暴漲。下面的分析都基於這個前提。
編碼演算法概覽
WebP：VP8/VP9 的靜態影像衍生
WebP 由 Google 於 2010 年發布，底層基於 VP8 視訊編碼器。有損壓縮使用 VP8 的幀內編碼（intra-frame coding），將影像分割為 4×4 和 16×16 的巨集區塊（macroblock），透過預測編碼和 DCT 變換壓縮。無損壓縮則使用獨立的演算法，基於 LZ77、Huffman 編碼和色彩快取等技術。
WebP 2（基於 VP9）的開發已在 2024 年被 Google 正式終止，現有的 WebP 格式不會再有重大技術更新。
AVIF：AV1 視訊編碼的靜態影像版
AVIF 基於 AV1 視訊編碼標準，由 Alliance for Open Media（AOMedia）於 2019 年正式發布。AV1 本身就是為了超越 VP9 和 HEVC 而設計的下一代視訊編碼器，AVIF 繼承了它的核心壓縮技術。
底層原理是將影像分割為可變大小的超級區塊（superblock，最大 128×128），支援高達 10 種方向性的幀內預測模式，搭配非對稱離散正弦變換（ADST）和精細的環路濾波器（loop filter + CDEF）。這些技術使 AVIF 在低位元率下的表現特別出色。
JPEG XL：專為攝影影像設計的全新架構
JPEG XL 由 JPEG 委員會於 2021 年正式發布，是從零設計的全新格式，不是基於任何現有視訊編碼器。它融合了 Google 的 PIK 實驗格式和 Cloudinary 的 FUIF 格式的技術。
JPEG XL 的有損壓縮使用 VarDCT 編碼（可變大小的 DCT 變換，區塊大小從 2×2 到 256×256），搭配自適應量化和名為 Squeeze 的基於小波的無損模式。它還有一個獨特的技術亮點：可以無損轉碼（transcode）現有的 JPEG 檔案，壓縮率約 20%，且轉碼過程完全可逆——你可以把轉碼後的 JXL 檔案完美還原為 bit-identical 的原始 JPEG。
壓縮效率實測比較
以下是使用 Kodak 標準測試圖集（24 張 768×512 照片）進行的壓縮效率測試，以 SSIM 0.95（接近視覺無損）為目標品質：
| 格式 | 平均檔案大小 | 相對 JPEG 壓縮率 | 編碼時間（相對值） | 解碼時間（相對值） |
|---|---|---|---|---|
| JPEG (mozjpeg) | 基準 100% | — | 1.0x | 1.0x |
| WebP | 基準的 72-78% | 節省 22-28% | 3-5x | 1.2x |
| AVIF (libaom speed 4) | 基準的 50-60% | 節省 40-50% | 50-100x | 1.5x |
| AVIF (libavif speed 8) | 基準的 55-65% | 節省 35-45% | 8-15x | 1.5x |
| JPEG XL (libjxl effort 7) | 基準的 55-65% | 節省 35-45% | 5-10x | 1.1x |
| JPEG XL (libjxl effort 3) | 基準的 60-70% | 節省 30-40% | 1.5-3x | 1.1x |
值得注意的幾個關鍵數據：
- AVIF 在低位元率下壓縮效率最高，但編碼速度極慢。以 libaom 的預設品質設定，編碼一張 4K 照片可能需要數十秒
- JPEG XL 在解碼速度上最接近 JPEG，這對瀏覽器渲染效能很關鍵
- WebP 的壓縮效率改進幅度最小，但生態系最成熟
功能特性完整比較
| 功能 | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| 有損壓縮 | 是 | 是 | 是 | 是 |
| 無損壓縮 | 否 | 是 | 是 | 是 |
| Alpha 透明度 | 否 | 是（有損+無損） | 是（有損+無損） | 是（有損+無損） |
| 動畫支援 | 否 | 是（WebP 動圖） | 是（AVIF 序列） | 是（JPEG XL 動畫） |
| 漸進式載入 | 是（Progressive JPEG） | 否 | 否（規格未支援） | 是（原生支援，效果優於 JPEG） |
| HDR 支援 | 否 | 否 | 是（10/12-bit，PQ/HLG） | 是（最高 32-bit float） |
| 色彩深度 | 8-bit | 8-bit | 8/10/12-bit | 最高 32-bit |
| 色域 | sRGB | sRGB | sRGB / Display P3 / BT.2100 | sRGB / Display P3 / BT.2100 / 任意 ICC |
| 最大解析度 | 65,535×65,535 | 16,383×16,383 | 8,193×4,353（Level 5.1） | 1,073,741,823×1,073,741,823 |
| JPEG 無損轉碼 | — | 否 | 否 | 是（約節省 20%） |
| 平行解碼 | 否 | 否 | 有限（tile-based） | 是（原生設計支援） |
幾個從架構角度看特別重要的差異：
漸進式載入是 JPEG XL 的殺手級功能之一。在慢速網路下，圖片可以從極低解析度逐步增強到完整品質，使用者體驗顯著優於 WebP 和 AVIF 的全載入或不載入的行為。
AVIF 的解析度上限是一個容易被忽略的技術限制。Level 5.1 規格下單幀最大約 8K 解析度，雖然可以透過 tile 拼接突破，但會增加實作複雜度。
JPEG XL 的最大解析度在規格上幾乎無限制（超過 10 億像素），這使它特別適合衛星影像、醫療影像等超高解析度應用場景。
瀏覽器與作業系統支援矩陣（2026 年 2 月）
| 平台 | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+（2013 年起） | 85+（2020 年起） | 已移除支援（Chrome 110 移除 flag） |
| Firefox | 65+（2019 年起） | 113+（2023 年起） | 已移除支援（Firefox 131 移除 flag） |
| Safari | 14+（2020 年起） | 16.1+（2022 年起） | 17+（2023 年起，唯一主流瀏覽器支援） |
| Android 系統 | 4.0+ | 12+ | 不支援 |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows（系統層級） | Windows 10+ | Windows 11 (22H2+) | 需安裝擴充 |
| macOS（系統層級） | Big Sur+ | Ventura+ | Sonoma+ |
這裡出現了一個令人遺憾的現實：JPEG XL 在 Chromium 核心瀏覽器中被移除了支援。Google 在 2022 年底以「生態系採用率不足」為由，從 Chrome 110 移除了 JPEG XL 的實驗性 flag。考慮到 Chromium 佔全球瀏覽器市場份額超過 65%，這個決定實質上阻礙了 JPEG XL 在 Web 端的普及。
目前 JPEG XL 在瀏覽器端僅 Safari 支援，但在桌面端軟體（Adobe 全家桶、GIMP、ImageMagick 等）和特定產業（攝影後製、數位典藏）已有穩定的採用。
實戰選擇指南
從系統架構的角度，選擇圖片格式需要考慮整個處理鏈路：上傳 → 轉碼 → 儲存 → CDN 分發 → 客戶端解碼。不同的場景適合不同的格式。
場景一：一般 Web 應用（部落格、電商、社群）
推薦格式：AVIF 為主，WebP 為 fallback
這是目前最務實的做法。使用 <picture> 元素提供 AVIF 和 WebP 兩個來源，瀏覽器會自動選擇支援的格式。AVIF 能提供最佳壓縮率，WebP 確保向後相容。完整的 lazy loading 與 responsive image 配置策略，可以延伸參考 網站圖片載入優化。
場景二：高解析度攝影作品展示
推薦格式：JPEG XL（若目標用戶以 Safari/macOS 為主）或 AVIF
攝影作品需要高色彩精度和漸進式載入，JPEG XL 在這方面最強。但如果需要跨瀏覽器支援，AVIF 的 10-bit 色彩深度和 HDR 支援也是不錯的選擇。
場景三：需要透明度的設計素材
推薦格式：WebP 或 AVIF
兩者都支援有損+Alpha 透明度，檔案大小遠小於 PNG。WebP 的相容性更好，AVIF 的壓縮率更高。
場景四：數位典藏與長期保存
推薦格式：JPEG XL
JPEG XL 的無損轉碼功能可以在不損失任何資料的情況下縮小 JPEG 檔案約 20%，且完全可逆。這對管理大量歷史影像的機構來說是極具吸引力的特性。
圖床服務如何應對格式多樣化
對於圖片託管服務而言，支援多格式是一個工程挑戰。需要在上傳端處理各種輸入格式，在分發端根據客戶端能力（通常透過 Accept header 的 content negotiation）提供最佳格式。
lpic.cc 目前支援 WebP 格式的上傳與儲存。如果你需要分享 WebP 格式的圖片，可以直接上傳取得分享連結。不過目前 lpic.cc 尚未提供伺服器端的自動格式轉換（例如上傳 JPEG 自動生成 AVIF 版本），如果你需要特定格式，建議在上傳前先用 Squoosh 或 ImageMagick 等工具轉換。
常見問題 FAQ
Q1：現在就該全面改用 AVIF 嗎？
還不到全面替換的時候。AVIF 的編碼速度仍然偏慢，不適合需要即時處理的場景（例如使用者上傳後即時轉碼）。建議採用 AVIF + WebP 雙格式策略，用 <picture> 元素讓瀏覽器自動選擇。
Q2：JPEG XL 還有未來嗎？
在 Web 端前景堪憂（Chrome/Firefox 已移除支援），但在專業影像處理、數位典藏、桌面端軟體等領域仍在穩步發展。Adobe Camera Raw、Affinity Photo 等專業工具已支援 JPEG XL。長期來看，如果 Apple 持續推動 Safari 支援，加上專業市場需求，JPEG XL 仍有機會找到自己的定位。
Q3：WebP 是不是要被淘汰了？
短期內不會。WebP 的瀏覽器支援率接近 97%，遠高於 AVIF 的約 92%。對於需要最大相容性的場景，WebP 仍然是最安全的選擇。但從壓縮效率來看，WebP 已經是三者中最弱的，未來會逐漸退居 fallback 角色。
Q4：為什麼 AVIF 編碼這麼慢？
AV1 編碼器的設計目標是最大化壓縮率，複雜的 RDO（Rate-Distortion Optimization）過程需要大量運算。libaom 的 speed 參數可以在速度與壓縮率之間取捨——speed 8 比 speed 4 快 5-10 倍，壓縮率僅損失約 5-10%。新的 SVT-AV1 編碼器在高 preset 下已經可以接近即時編碼。
Q5：轉換格式會損失畫質嗎？
有損到有損的轉換（例如 JPEG → WebP/AVIF）一定會有額外的品質損失，因為每次有損壓縮都會引入新的壓縮瑕疵。最佳做法是從無損來源（如 RAW、TIFF、PNG）直接轉換到目標格式。如果只有 JPEG 來源，JPEG XL 的無損轉碼是唯一不損失品質的選項。這個 generation loss 現象在 SSIM 圖床壓縮品質實測 的實驗裡也能清楚觀察到各家圖床的再壓縮代價。