快速結論：按流水線挑，不要跟著格式熱度走
對 2026 年多數網站來說，從 JPG、PNG 升級成一個「單一現代格式」，最穩的一步就是換成 WebP。當流水線能同時輸出 WebP 或 JPEG 回退時，AVIF 才是更好的首選。
後半句正是很多 AVIF vs WebP 對比會跳過的部分。最好的格式，不是基準測試上跑出最小檔案的那個，而是你的 CMS、CDN、建置流程、訪客瀏覽器分布和圖像類型能穩定送達的那個。
作為實務起點，可以這樣想：
- 用 WebP：想要一個簡單的現代格式、快速批次轉換、廣泛支援，以及在舊瀏覽器、郵件用戶端、CMS 外掛、App 內嵌瀏覽器上少踩坑時。
- 搭配回退地用 AVIF：圖像已經是一大塊效能成本，你能在建置時或透過圖片 CDN 編碼，也能在上線前肉眼確認效果時。
- 保留 JPEG 或 PNG 回退：圖像必須在各種環境下都能開啟，例如舊 Safari / iOS、被鎖版本的企業瀏覽器、爬蟲、郵件用戶端、第三方平台。
AVIF vs WebP 一覽
| 觀點 | WebP | AVIF |
|---|---|---|
| 最佳預設用途 | 大多數網站的單一現代格式 | 多格式流水線裡的第一個 source |
| 壓縮 | 比 JPEG/PNG 小；穩定的全能型 | 照片上通常比 WebP 更小 |
| 瀏覽器支援（2026 年 7 月） | Can I use 上約 96 % 全球使用者支援 | Can I use 上約 93 % 全球使用者支援 |
| 編碼速度 | 對本機與批次工作流足夠快 | 較慢；比較適合建置時、CDN 或離線處理 |
| 解碼風險 | 在各家瀏覽器上都非常成熟 | 大多沒問題，但大 hero 圖要在低階裝置上實測 |
| 透明度 | 支援 | 支援 |
| 動畫 | 支援，且使用廣泛 | 格式支援，但工具/瀏覽器工作流的可預測性較低 |
| 色彩深度與 HDR | 面向 8 位元的 Web 傳輸 | 對高位元深度、HDR、廣色域工作流更適合 |
| 最擅長的圖像類型 | 商品照、部落格配圖、螢幕截圖、縮圖、通用 Web 素材 | 圖片密集頁面、大 hero、圖庫、高流量靜態素材 |
它們從哪裡來
WebP 由 Google 開發，2010 年公開發布。有損模式基於 VP8 影片編碼，無損模式使用另一套壓縮方式。Google 的 WebP 文件指出，WebP 支援有損壓縮、無損壓縮、透明與動畫，並在主流瀏覽器上獲得原生支援。
AVIF 是 AV1 Image File Format 的縮寫，建立在開放影片編碼 AV1 之上。web.dev 把 AVIF 描述為一種較新的點陣圖格式，目標是覆蓋 Web 上常見的圖像需求，例如透明、動畫，以及相較舊格式提供更好的「每位元組畫質」。
實務上真正的差距其實是「年紀」。WebP 有超過十年時間慢慢融入瀏覽器、CMS 外掛、設計軟體、圖像函式庫與建置系統。AVIF 已經不算新奇，但仍然是最容易碰到編碼慢、缺少匯出選項，或者某個平台仍要求回退的那個格式。
壓縮效率
在相近畫質下，AVIF 在攝影類圖像上通常比 WebP 更小。但這不代表每張 AVIF 都會小 30 %、40 % 或 50 %。實際數字取決於編碼器、品質設定、圖像內容，以及你怎麼判斷「同樣畫質」。
差距最明顯的場景：
- 含天空、膚色、陰影和漸變的大 hero 照片；
- 每一 KB 都會在多張圖之間反覆分發的圖庫；
- 行動裝置頁面——傳輸量減少直接改善 LCP 和用量。
差距通常會縮小的場景：
- 小縮圖——請求開銷和縮放成本比編碼效率影響更大；
- 螢幕截圖、UI 圖、帶清晰文字的示意圖；
- 雜訊或紋理特別豐富的圖像；
- 無損圖形——PNG 或無損 WebP 有時仍然更合理。
真實專案請拿一份有代表性的資料夾去測，而不是一張挑好的樣圖。強健的測試集通常包含：hero 照片、商品圖、人像、螢幕截圖、插畫、縮圖。都按你實際發佈的尺寸來比檔案大小和畫面。
2026 年的瀏覽器支援
兩種格式的支援都很廣，但並不完全相同。2026 年 7 月核對時，Can I use 顯示 WebP 全球使用者支援約 96.15 %，AVIF 約 93.42 %。兩者都能在現代 Web 上正常投產，但不能算是等同。
剩餘的差距在下列地方特別要緊：
- 舊 iPhone 和 iPad，尤其是 iOS 15 及更早版本；
- 舊版桌面 Safari；
- 瀏覽器版本被凍結的企業用電腦；
- App、資訊站、老 Android WebView 內嵌瀏覽器；
- 那些行為跟正常瀏覽器不太一樣的郵件用戶端和第三方平台。
對 WebP，多數網站用「WebP + 舊用戶端 JPEG 回退」就夠用。對 AVIF，安全的生產配置仍然是 AVIF 優先、WebP 其次，JPEG 或 PNG 兜底。
<picture>
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img src="/images/hero.jpg" alt="使用中的產品照片">
</picture>
順序有意義。瀏覽器會選自己支援的第一個 source，所以想讓支援 AVIF 的瀏覽器拿到 AVIF，就要把它放在 WebP 之前。
編碼速度
真的在維護一個網站時，你最能感覺到的差異，其實就在編碼速度。
WebP 對本機轉換、批次工具、CMS 工作流和簡單的靜態站點建置都夠快。AVIF 會明顯更慢，因為編碼器要花更多力氣去找更小的結果。雖然有較快的 AVIF 預設，但通常要拿一部分壓縮率作交換。
它會在四個地方咬人：
- 靜態建置： 30 張圖的部落格沒問題。原始素材 2000 張的旅遊網站，AVIF 生成很容易變成一筆實實在在的建置成本。
- 使用者上傳： 使用者上傳後期待秒出預覽的場景，AVIF 編碼會把延遲與 CPU 成本抬起來。
- 無伺服器函式： 慢編碼容易撞到逾時或成本上限。
- 本機工作流： 手動把一整個資料夾在上傳前轉好，用 WebP 明顯輕鬆很多。
一個實用的判斷：編碼一次、分發很多次的場景交給 AVIF；重視速度、簡單和可重複批次轉換的場景交給 WebP。
不同圖像類型下的畫質
AVIF vs WebP 不是一個涵蓋整站的決定。
| 圖像類型 | 更好的第一選擇 | 原因 |
|---|---|---|
| 大 hero 照片 | AVIF + WebP 回退 | AVIF 能明顯減輕首屏上最重的素材 |
| 部落格內文照片 | WebP，或在自動化情境下 AVIF + 回退 | WebP 簡單；如果建置流程已經在產生多種變體，AVIF 值得上 |
| 電商商品照 | 基線用 WebP，再測 AVIF | 商品細節必須乾淨——重點比較邊緣、材質、標籤和顏色 |
| 螢幕截圖或 UI 圖 | WebP 或 PNG | 低品質 AVIF 會讓小字和硬邊變糊 |
| logo 或圖示 | SVG 或 PNG/WebP | 點陣 AVIF 不適合向量類圖形 |
| 動圖 | WebP 或影片 | 動畫 AVIF 的工具與平台工作流還不夠成熟 |
| 社群分享圖 | JPEG 或 WebP | 很多社群/即時通訊平台反正會重新壓縮 |
進階能力
AVIF 支援一些 WebP 沒有同樣瞄準的能力。對普通的 sRGB Web 圖像，這些可能無關緊要；但在攝影、HDR 內容和高階顯示流水線裡，它們就有意義了。
- 高位元深度： AVIF 可以承載超過 Web 常見 8 位元的位深。
- HDR 與廣色域： 如果流水線能保留這些訊號，AVIF 更契合。
- AV1 生態： AVIF 繼承了 AV1 生態的一部分能力，包含高效的畫格內壓縮。
如果整條流水線沒辦法保留這些訊號，就別為了這些能力去選 AVIF。當來源已經是普通的 sRGB JPEG，還會經過一個會把中繼資料與色彩資訊剝掉的 CMS，真正的實惠通常只是「檔案更小」，而不是「HDR 魔法」。
工具鏈成熟度
WebP 是那個「無聊但成熟」的選項——這是誇獎。瀏覽器、設計軟體、圖像函式庫、建置外掛、CMS 外掛和 CDN 都把它支援得很好。出狀況時，除錯也相對容易。
AVIF 的支援已經好很多了，但稜角還是比較容易碰到：
- CMS 可以上傳 AVIF，但沒有生成所有縮圖尺寸；
- 某個外掛產出了 AVIF，卻沒寫回退標記；
- CDN 只在特定方案或特定 Accept 標頭下才會用 AVIF；
- 本機瀏覽器內編碼，某些瀏覽器成功、另一些直接失敗；
- 為每張圖都產生 AVIF 後，建置明顯變慢。
在大網站上真正切到 AVIF 之前，先把這條真實流水線走通並驗證：上傳、縮放、生成變體、渲染 HTML、部署、爬取，再分別在 Safari、Chrome、Firefox 和一台低階手機上開開結果。
該選哪一個
2026 年多數 Web 專案的務實選擇是 WebP。當流水線準備好之後，AVIF 才是那張效能牌。
遇到以下情境用 WebP
- 想要一個幾乎哪裡都能跑的現代圖像格式。
- 需要快速的本機或瀏覽器端轉換。
- 網站規模不大，圖像傳輸不是最大的效能瓶頸。
- CMS 或電商平台無法產出乾淨的 AVIF 回退。
- 圖像裡有大量螢幕截圖、示意圖、UI 截圖或小縮圖。
- 圖像會被送到郵件、市集或第三方平台，AVIF 支援情況不確定。
遇到以下情境用 AVIF（配 WebP 或 JPEG 回退）
- 圖像佔據頁面重量或 LCP 的主要部分。
- 你有大量大照片、圖庫、hero 圖或多媒體密集的著陸頁。
- 你能在建置時、透過 CDN 或在離線流水線裡編碼。
- 工具鏈能自動輸出 AVIF、WebP、JPEG/PNG 回退標記。
- 你能在真實圖像上檢查畫質，而不是只信一份基準測試。
- 你的讀者大多使用現代瀏覽器。
遇到以下情境保留 JPEG 或 PNG
- 圖像要撐得住舊用戶端、郵件、文件或下載場景。
- 你需要一份用來編輯或封存的母版檔。
- 圖像是 logo、圖示、示意圖或截圖，無損輸出很關鍵。
- 平台反正會對上傳做一次重壓縮。
如何在你自己的網站上比 AVIF 和 WebP
不要只憑一份通用基準下結論，用你自己的圖像來測。
- 挑 10 到 20 張真實圖像：hero 照片、商品照、縮圖、螢幕截圖，還有任何帶文字的圖。
- 用合理的品質設定分別匯出 WebP 和 AVIF。第一輪可以先比較 WebP 80–85、AVIF 60–75，然後再依肉眼微調。
- 依最終的渲染尺寸看結果，不要只在 100 % 縮放下看。
- 仔細看人臉、天空、漸變、材質、商品標籤、文字和硬邊。
- 比整頁圖像總重量，而不是只看一張。
- 前後各跑一次 Lighthouse 或你慣用的效能工具。
- 在瀏覽器裡關閉 AVIF 支援，或換一台不支援 AVIF 的裝置開啟頁面，測一次回退渲染。
如果 AVIF 只在一張縮圖上省了幾 KB，那就別搞這套複雜度；如果它能從 LCP hero 裡砍掉幾百 KB，那就搭上回退標記用起來。
用 PhotoTools 做快速轉換
當你需要在圖像進網站前，先在手邊檢查或準備一下檔案時，PhotoTools 就派得上用場。
- 想要一個能覆蓋大多數現代網站、純瀏覽器本機的快速匯出，用 JPG 轉 WebP 轉換器。
- 想在真的搭流水線之前先把 AVIF 版和 WebP 版比一比，用 JPG 轉 AVIF 轉換器。
- AVIF 檔案要交給打不開它的工具、客戶或平台時，用 AVIF 轉 JPG 或 PNG。
轉換器透過瀏覽器原生的 Canvas API 在本機執行。對於快速批次和「不上傳」的工作流很方便，但它不是大型網站上自動 CDN 或建置流水線的替代品。
參考資料
本文於 2026 年 7 月 18 日對照以下最新的格式與支援指引進行了核對：Google 的 WebP 文件、web.dev 的 AVIF 指南、Chrome Lighthouse 對現代圖像的建議、Can I use AVIF 和 Can I use WebP。