把同一張照片分別轉成 WebP 與 AVIF，AVIF 通常能再瘦身二到三成，這也是它常被捧成「下一代最強圖片格式」的原因。不過，同一套編碼器換一種情境測試，結果卻完全不一樣，在不允許任何畫質損失的無失真壓縮設定下，AVIF 有多款編碼設定測出來的檔案，竟然比原始 PNG 檔案還要肥大，WebP 的無失真壓縮反而穩定省下四成多容量。Cloudinary 工程師實測同一張圖片就出現這種反差，AVIF 在其中一組設定的節省率是負的三成四，等於比原圖還大三成四，編碼還花了二十幾秒；WebP 同等情境下卻只花不到零點一秒，就穩穩省下四成七的容量。
這代表「最新格式一定全面壓過舊格式」這句話，套進不同用途反而會踩空。WebP 與 AVIF 這兩種圖片格式的差異，真正該拆開來看的是三件事：檔案能壓多小、瀏覽器吃不吃得下、編碼要花多少成本，而且答案會因為你是要處理行銷主視覺，還是要處理使用者自己上傳的圖片，分出完全不同的選擇。先從兩者的身世與技術底子講起，再一路拆到實際數字與情境選擇。
WebP 是什麼？靠什麼技術把檔案壓得比 JPEG 小？
WebP 是 Google 在 2010 年推出的圖片格式，設計目的很單純，就是把 JPEG、PNG、GIF 三種舊格式的工作，一次收進同一套壓縮技術裡。它的有損壓縮建立在 VP8 影片編碼器之上，借用影片壓縮預測像素區塊的技術來處理靜態圖片；無失真壓縮則是另一套轉換技術，專門處理不能有任何畫質損耗的圖檔。
根據 MDN Web Docs 的整理，有損 WebP 平均比同品質的 JPEG 小 25% 到 35%，無失真 WebP 平均比 PNG 小 26%。對一個網站來說，這代表同一批商品照、部落格配圖換成 WebP，就能省下四分之一到三分之一的傳輸量，不必額外犧牲畫質。
除了壓縮率，WebP 還原生支援 alpha 通道透明背景與動畫，一套格式就同時取代了 JPEG 的有損壓縮、PNG 的透明與無失真，以及 GIF 的動畫。也因為推出得早，WebP 已經是圖片格式裡的老將，瀏覽器、圖片編輯軟體、CDN 服務對它的支援都相對成熟，不太需要擔心工具鏈跟不上。
AVIF 是什麼？比 WebP 晚推出的下一代格式
AVIF 是開放媒體聯盟（Alliance for Open Media）在 2019 年推出的圖片格式，同樣是把影片編碼技術搬到靜態圖片上，這次借用的是更新的 AV1 影片編碼器。開放媒體聯盟由 Google、Mozilla、Netflix 等公司組成，AVIF 跟 WebP 一樣是開放原始碼、免權利金的格式，不必額外付費授權。
如果說 WebP 解決的是壓縮率的問題，AVIF 想做的是再往前一步，在同樣講求小檔案的前提下，補上 WebP 沒有的進階能力。WebP 只支援 8-bit 色深，AVIF 最高可以到 12-bit，還多了 WebP 沒有的高動態範圍（HDR）與寬色域支援，這些對一般網頁縮圖沒什麼感覺，但對追求畫質細節的精修照片就有差。
換句話說，AVIF 是後起之秀，技術規格比 WebP 新，但因為推出得晚，瀏覽器版本、圖片編輯工具的支援還在追趕當中，跟前面 WebP 已經成熟的生態系剛好形成對照。
壓縮率、瀏覽器支援與編碼速度，實際數字怎麼比？
WebP 與 AVIF 該怎麼選，答案不會是「AVIF 全部都贏」這麼簡單。把兩者放在同一個擂台上看，至少要拆成四個面向分開比：同一張照片的壓縮率誰比較小、瀏覽器實際吃不吃得下、編碼要花多久時間，以及色彩與動態表現誰比較齊全。
這四個面向裡，有兩個地方特別容易讓人跌破眼鏡。一個是無失真壓縮的情境，AVIF 不見得比 WebP 划算；另一個是瀏覽器支援度，舊資料常常還停留在「AVIF 支援度不夠、WebP 才安全」的印象，但現在的狀況已經不是這樣。以下逐項拆開講。
同一張照片，壓縮率差多少？
同一張採用一般有損壓縮的照片，AVIF 通常比 WebP 再小二到三成，這是整個比較裡最常被拿出來說嘴的數字。根據 MDN Web Docs 引用的比較數據，把同一組 JPEG 圖集分別轉檔，AVIF 的壓縮率中位數落在五成左右，WebP 則約三成；相較 JPEG，Google web.dev 也指出 AVIF 可以省下超過五成的容量。
要提醒的是，這些數字都是中位數或平均值，不是固定不變的公式。實際能省多少，會因為圖片本身的內容（照片、插畫、截圖）、選擇的編碼設定（品質、速度）不同而有落差，同一套壓縮技術，拿去壓一張色塊分明的截圖跟一張細節豐富的風景照，節省幅度可以差很多。這也是為什麼下一節要特別拆出無失真壓縮這個例外情境。
無失真壓縮時，AVIF 不一定是比較划算的選擇
多數討論 WebP 跟 AVIF 的文章，講到壓縮率就直接下結論「AVIF 全面勝出」，但這句話只在有損壓縮的前提下成立。換成無失真（lossless）壓縮，也就是完全不能犧牲任何一個像素的情境，結果會反過來。
Cloudinary 工程師 Jon Sneyers 在一篇實測分析裡，對同一張圖片跑無失真壓縮：WebP 在 z6 設定下省下 47.11% 的容量，只花 0.038 秒；AVIF 在 s2 設定下的節省率是負的 34.28%，等於比原始檔案還大三成四，編碼卻耗時 23.3 秒。多數 AVIF 無失真設定測出來的結果，都落在編碼更慢、檔案卻更肥大的區間裡。
這代表 AVIF 的壓縮優勢集中在有損壓縮的照片類型上，不是每一種圖都該無腦選它。如果手上的圖需要完全保留像素細節，例如某些設計稿、線稿，WebP 的無失真壓縮反而是比較穩定、划算的選擇，這個邏輯，會在後面談使用者上傳圖片時再展開一次。
瀏覽器支援度，兩者其實都已經追上來了
不少文章還在引用「AVIF 支援度只有九成初、WebP 才是安全牌」這種舊印象，但用目前的瀏覽器版本資料對照，這個差距已經幾乎打平。
根據 caniuse.com 的資料，AVIF 目前在 Chrome 85 以上、Edge 121 以上、Firefox 93 以上、Opera 71 以上都完整支援，Safari 從 16.4 版開始完整支援（16.1 到 16.3 是部分支援），iOS 版 Safari 則從 16.0 開始支援，Samsung Internet 14 以上也支援。WebP 的部分支援得更早也更廣，Chrome 32 以上、Edge 18 以上、Firefox 65 以上、Opera 19 以上都支援，Safari 從 16.0 開始完整支援（14 到 15.6 是部分支援），iOS 版 Safari 則從 14 開始就支援。
換句話說，兩者在所有主流桌機與行動瀏覽器的最新版本都已經支援，差距主要只剩下極舊版本，或是 Internet Explorer 這類已經停止更新的瀏覽器，這些版本本來就不該是你優化的目標對象。這也代表相容性已經不再是兩者的主要決勝點，真正該比較的重心，該移到壓縮率跟編碼成本上。
編碼速度差多少，為什麼 AVIF 轉檔比較慢？
AVIF 編碼速度比 WebP 慢，原因要回到它們各自借用的影片編碼器。WebP 有損壓縮的底子 VP8，本來就是為即時通訊、串流這類講求速度的影片場景設計；AVIF 借用的 AV1 則是設計來處理非即時的高畫質影片壓縮，運算複雜度本來就比較高，套用到單張圖片壓縮，成本自然跟著墊高。
根據 Cloudinary 的實測，在一般品質設定下，WebP 編碼器 cwebp 壓一張圖大約只要 0.9 秒，AVIF 編碼器在對應的品質設定卻要花上 4.2 秒，單張圖片看起來差距不大，但如果是網站後台一次要處理成百上千張使用者上傳的圖片，這個落差會被大量圖片直接放大成明顯的伺服器負擔。
好消息是，AVIF 的編碼速度正持續在進步。Google web.dev 的資料指出，AVIF 編碼器 libaom 從 Chrome 加入 AVIF 支援時的 2.0.0 版本，到後續的 3.1.0 版本，同樣設定下的靜態圖片編碼所需 CPU 運算量已經降低約 6.5 倍；如果搭配硬體加速編碼器，速度更可以比純軟體編碼快上 7 到 23 倍。只是現階段，這個速度落差還是實際存在，不能假裝它不影響選型判斷。
色彩深度與動態圖片，AVIF 比 WebP 多支援了什麼？
除了壓縮率跟編碼速度，AVIF 在畫質細節以外還多了幾項進階能力。色彩深度上，WebP 只支援 8-bit，AVIF 可以到 12-bit；高動態範圍（HDR）與寬色域這兩項，AVIF 都有支援，WebP 則完全沒有。
AVIF 還額外支援膠卷顆粒合成（film grain synthesis）與漸進式解碼這類影像處理功能，膠卷顆粒合成可以在壓縮時先移除雜訊、傳輸更小的檔案，再由瀏覽器端重新合成顆粒質感，讓畫面看起來更自然。動畫這塊兩者都支援，但底層的編碼原理不同，壓縮效率也不會完全一樣。
這些差異主要在高保真度視覺內容才體會得到，像是精修過的商品照、風景大圖，或是需要保留漸層細節的設計稿。放到一般網站常見的部落格配圖、縮圖或使用者上傳圖片，兩者在肉眼可辨識的畫質差異上其實不明顯。
行銷主視覺與精修照片，什麼時候該選 AVIF？
把前面幾節的數字套進實際情境，第一個該優先考慮 AVIF 的，是行銷主視覺跟精修過的商品照片。
這類圖片有一個共同特徵，數量相對少，而且可以在上架前就先離線批次編碼好，不需要即時處理。既然編碼時間不是問題，AVIF 在壓縮率跟色彩深度上的優勢就能完全發揮。舉例來說，一個電商品牌要放上首頁的主視覺照片，通常只有幾張，設計團隊會先精修過再上傳，這種情境正好吃到 AVIF 的強項。
根據 Google web.dev 引述 CDN 業者 Imgix 的部落格數據，AVIF 相較 JPEG 可以省下約 60% 的檔案大小，相較 WebP 也能再省下約 35%，對首頁大圖、商品精修照這種容易拖慢最大內容繪製（LCP）的元素，能有效縮短載入時間。換句話說，只要圖片數量不多、能事先處理好，AVIF 多花的那幾秒編碼時間根本不是問題，換來的畫質與檔案大小雙重優勢反而划算。
使用者上傳的內容，為什麼 WebP 更務實？
換成另一種情境，使用者自己上傳的圖片，像是論壇貼文附圖、社群留言裡的照片，或是電商賣家自行上傳的商品圖，答案就會反過來，WebP 反而更務實。
這類場景的圖片數量通常很大，而且需要在使用者上傳的當下，就即時或近即時產生縮圖與壓縮版本，不像行銷主視覺可以慢慢離線處理。前面提過，一般品質設定下 AVIF 編碼一張圖的時間是 WebP 的四倍以上，單張圖片這個差距感覺不到，但換成一天要處理成千上萬張使用者上傳的圖，AVIF 多出來的編碼成本會被大量圖片直接放大成實實在在的伺服器運算負擔，而多數網站的伺服器資源本來就有限，不會為了圖片壓縮特別加開運算資源。
這種情況下，WebP 夠好又夠快的特性反而比較適合，壓縮率雖然不是最頂尖，但編碼速度快、對伺服器負擔小，加上圖片編輯軟體跟舊裝置對 WebP 的支援已經很成熟，處理起來的風險也比較低。這也呼應前面無失真壓縮那節的邏輯，不是每種圖都該無腦選最新格式，量大又要即時處理的圖，穩定省時間往往比極致壓縮率更重要。
AVIF 與 WebP，可以一起使用嗎？
看到這裡，你可能已經發現，WebP 跟 AVIF 各有各的優勢，不必被迫二選一。實務上常見的做法，是用 <picture> 元素依優先順序放進多個 <source>，讓瀏覽器自己去挑它支援的第一個格式：
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="說明文字">
</picture>Code language: HTML, XML (xml)瀏覽器會由上而下依序檢查，支援 AVIF 的就載入 AVIF，不支援就退回檢查 WebP，兩者都不支援才落到最後的 JPEG。這種寫法同時兼顧了新格式的壓縮優勢，與舊瀏覽器的相容性，是靜態頁面最簡單的做法。
如果是動態伺服器，還有另一種替代做法。瀏覽器發出圖片請求時，會在 Accept 請求標頭裡宣告自己支援哪些格式，伺服器端可以依這個標頭做內容協商，直接回傳對應的圖檔格式，不需要在前端寫多組 <source>。兩種做法適合的情境不太一樣，<picture> 元素適合版型固定的靜態頁面，Accept 標頭協商則更適合需要動態產生圖片版本的伺服器架構。
WebP 跟 AVIF 都不是萬用解方。AVIF 贏在有損壓縮的壓縮率跟色彩表現，WebP 贏在編碼速度跟相容性的穩定度，把兩者的差異攤開來看，真正該問的問題，從來不是哪個格式比較新，而是這批圖片準備怎麼被產生、誰要即時處理它。行銷主視覺可以放心把畫質與壓縮率的最後一哩路交給 AVIF，量大又講求即時的使用者上傳圖片，交給 WebP 反而更省心。
隨著硬體加速編碼器逐漸普及，AVIF 編碼速度的落差應該還會持續縮小，兩種格式的界線也可能愈來愈模糊。但在那天到來之前，先想清楚自己的圖片是誰在產生、什麼時候要用，再決定要不要換上最新的格式，會是比較踏實的做法。
</content>