WebP vs AVIF：解碼成本翻轉贏家
AVIF 壓得比 WebP 更小，但在低階手機上解碼成本會吃掉省下的傳輸時間。這篇呈現檔案大小、解碼、下載的正面對決數據，以及五個決策標準。
我們問了什麼
AVIF 壓得比 WebP 更小，這已有充分文獻記載。但壓縮率只是一個軸線。我們要的是完整圖像：檔案大小、解碼成本、下載時間，以及在不同 CPU 等級和網路情境下的合計繪製時間。
問題是：AVIF 更高的壓縮率是否轉化為更快的投放體驗，還是解碼成本會把它吃掉？
怎麼測的
基準測試總覽中的兩個實驗適用於此：
- 實驗 A（3,375 次）：localhost 上的解碼成本，3 種 CPU 等級（1x 桌機、4x 中階、6x 低階），無網路雜訊。
- 實驗 B（2,250 次）：完整 CDN 路徑，2 種網路情境（fast 4G、slow 3G），每次記錄 cold/warm。
75 張正式環境圖片（25 JPEG、25 GIF、25 PNG）。每張圖轉成 WebP 和 AVIF，品質 q80。每次測量用新的無痕視窗。CDP 控制 CPU 節流和網路模擬。
測出了什麼
檔案大小節省幅度（越高越好）
p25 / p50 / p75 是各來源格式 25 張圖的四分位數。半數圖片至少省到 p50 的幅度。
| 來源 | 目標 | p25 | p50 | p75 |
|---|---|---|---|---|
| JPEG | WebP | 45.1% | 47.1% | 53.3% |
| JPEG | AVIF | 33.7% | 38.2% | 43.8% |
| GIF | WebP | 41.1% | 51.0% | 61.6% |
| GIF | AVIF | 46.6% | 54.0% | 63.3% |
| PNG | WebP | 81.1% | 82.9% | 85.6% |
| PNG | AVIF | 79.4% | 81.0% | 85.1% |
在相同 q 下，WebP 壓 JPEG 和 PNG 的幅度大於 AVIF。AVIF 壓 GIF 多一些（54% vs 51%），差距 3 個百分點。光看檔案大小，兩種格式都沒有壓倒性優勢。
解碼時間（越低越好）
解碼時間是 CPU 把下載完的位元組轉成像素的工作量。img.decode() API 在沒有網路的情況下獨立測量。
| CPU 等級 | 原始格式 (p50) | WebP (p50) | AVIF (p50) |
|---|---|---|---|
| 桌機 (1x) | 1.2 ms | 2.2 ms | 7.6 ms |
| 中階手機 (4x) | 1.6 ms | 2.5 ms | 3.9 ms |
| 低階手機 (6x) | 2.3 ms | 3.4 ms | 31.9 ms |
在桌機上，AVIF 解碼 7.6 ms，可以接受。在低階裝置上，AVIF 跳到 31.9 ms。WebP 維持 3.4 ms。差距 28.5 ms。
這是整個基準測試中最大的單一差異。AV1 解碼器比 WebP 解碼器耗更多 CPU，而且成本隨 CPU 節流倍數放大。
真實 CDN 上的下載時間（越低越好）
下載時間是完整的來回：從送出請求到最後一個位元組到達。在正式環境的 CDN 路徑上跑，不是 localhost。
| 網路 | 原始格式 (p50) | WebP (p50) | AVIF (p50) |
|---|---|---|---|
| Fast 4G | 265.8 ms | 193.2 ms | 190.9 ms |
| Slow 3G | 916.6 ms | 532.4 ms | 543.3 ms |
在 fast 4G 上，AVIF 和 WebP 差不到 3 ms。在 slow 3G 上，WebP 快 11 ms。下載數字接近，因為兩種格式對同一張來源圖產生類似的檔案大小。
合計：下載加解碼
這張表把每張圖的下載中位數和解碼中位數相加，再取 75 張圖的最小 / p50 / 最大值。Slow 3G，中階手機（4x CPU 節流）。
| 格式 | 最小值 (ms) | 中位數 (ms) | 最大值 (ms) |
|---|---|---|---|
| 原始格式 | 438 | 939 | 6,777 |
| WebP | 410 | 534 | 1,466 |
| AVIF | 413 | 547 | 1,406 |
WebP 中位數 534 ms，AVIF 中位數 547 ms。兩者都大幅贏過原始格式。WebP 在中位數上領先 13 ms。
在低階手機（6x）上差距更大，因為 AVIF 的解碼成本成長得比 WebP 快。
低電量與熱節流
4x 和 6x CPU 的列模擬中階和低階手機。但它們也代表另一件事：壓力下的旗艦手機。
- Apple 的低電量模式在大多數裝置上關閉 5G，並限制 CPU 速度。
- 獨立基準測試顯示此模式下 CPU 分數降低 30% 到 40%。
- 許多 Android 省電模式也會限制 CPU 時脈。
- 過熱的手機用同樣的方式降低 CPU（熱節流）。
旗艦手機可以暫時表現得像 4x 那些列，搭配更慢的網路。弱 CPU 的格子涵蓋的使用者遠多於低階手機的市佔率。這些格子正是 WebP 低解碼成本贏得最大的地方。
交叉模型：損益平衡頻寬
實驗 A 產出了一個交叉模型。對每張圖和每個 CPU 等級，我們計算 AVIF 省下的位元組剛好抵消額外解碼成本的頻寬。低於這個頻寬，AVIF 較小的檔案贏。高於它，網路夠快，解碼成本主導。
| 轉換 | CPU 等級 | 中位數損益平衡 (Mbps) |
|---|---|---|
| GIF 轉 WebP | 桌機 | 22.8 |
| GIF 轉 WebP | 低階 | 5.8 |
| GIF 轉 AVIF | 桌機 | 36.9 |
| GIF 轉 AVIF | 低階 | 9.5 |
| JPEG 轉 WebP | 桌機 | 37.6 |
| JPEG 轉 WebP | 低階 | 5.8 |
| JPEG 轉 AVIF | 桌機 | 7.5 |
| JPEG 轉 AVIF | 低階 | 1.8 |
| PNG 轉 WebP | 桌機 | 442.1 |
| PNG 轉 WebP | 低階 | 391.7 |
| PNG 轉 AVIF | 桌機 | 100.7 |
| PNG 轉 AVIF | 低階 | 24.9 |
WebP 的損益平衡頻寬從 5.8 到 442 Mbps。對大多數真實網路，WebP 一律勝出。AVIF 的損益平衡較低（1.8 到 100 Mbps）。在快速網路上，AVIF 的解碼成本可以超過省下的下載時間。
PNG 轉 WebP 的損益平衡最高（391 到 442 Mbps）。PNG 省的位元組太多，只有極快的網路才能讓解碼成本變得重要。
五個標準：計分卡
涵蓋率（WebP 贏）。 直接替換沒有 fallback 時，每少 1% 就是丟掉的曝光。WebP 97% 丟 3%。AVIF 95% 丟 5%。
解碼成本（WebP 贏）。 在低階手機上，AVIF 解碼 31.9 ms。WebP 是 3.4 ms。差 9 倍。
編碼速度（WebP 贏）。 JPEG 來源轉 WebP 中位數 14 ms。AVIF 要 340 ms，慢 24 倍。GIF 來源差距 40 倍（45 ms vs 1,793 ms）。轉換服務不需要因為 WebP 加機器。
無損模式（WebP 贏）。 另一組測試把 25 張 PNG 做像素完全相同的無損轉換。每張 WebP 都比對應的 AVIF 小。AVIF 中位數大 1.27 倍。
動畫支援（WebP 贏）。 libvips 原生寫 animated WebP。Animated AVIF 需要特殊的 ffmpeg 路徑，因為 libvips 寫不了 HEIF 序列時序。完整故事見 Part 01。
相同品質下的壓縮率（AVIF 贏）。 AVIF 壓縮率上限更高。在相同 SSIM 下，AVIF 檔案更小。但這個優勢有前提：需要 fallback（例如 <picture>），讓 5% 不支援 AVIF 的瀏覽器退回 WebP 或原始格式。沒有 fallback，這個差距就變成丟掉的使用者。這就是為什麼 AVIF 放在 M2。
對投放體驗的意義
壓縮率最高的格式不是繪製最快的格式。在對投放最重要的裝置和網路上，解碼成本抵消了壓縮優勢。
WebP 贏是因為三個軸線都平衡：不錯的壓縮、低解碼成本、廣涵蓋率。AVIF 紙面上是更好的格式。WebP 是現在部署更好的格式。
品質設定、涵蓋率缺口，以及通往 AVIF 的路，見 Part 03：部署 WebP。
參考來源：
- https://caniuse.com/webp（WebP 瀏覽器支援度，97%）
- https://caniuse.com/avif（AVIF 瀏覽器支援度，95%）
- https://support.apple.com/en-us/101604（Apple 低電量模式）
- https://developer.chrome.com/docs/devtools/device-mode#cpu（Chrome DevTools CPU 節流預設值）
延伸閱讀： 回到基準測試總覽，或讀 Part 01：GIF 轉 Animated WebP。