圖片永遠是網站最肥的資源類別。2026 年回頭看 HTTPArchive 的中位數，桌機版頁面每篇平均載入約 2.4 MB，其中超過六成是圖片；手機版更尖，圖片佔比逼近七成。換句話說，所有頁面速度的努力，最後幾乎都要回到圖片上算總帳。

過去十幾年的解法很單純，圖片從 JPEG 跳到 WebP，檔案大概省下三到四成。2026 年的選項多了一個，叫做 AV1 Image File Format（AVIF）。同一張照片改成 AVIF，壓縮率可以再多砍三到五成，連 Safari 都終於完整支援。但這不代表 WebP 就該整批退役，AVIF 編碼成本高、舊版瀏覽器仍有殘餘份額、外掛生態系也還在追趕。

這篇文章把 webp avif 圖片壓縮 在 2026 年的選擇邏輯一次釐清，從格式特性、瀏覽器支援、外掛工具到三種典型站台的取捨，最後補上回退語法該怎麼掛，讓你不必把整個媒體庫翻過一遍，就能拿到大部分的速度紅利。

兩種格式的起源與壓縮特性

WebP 是 Google 在 2010 年公開的開源格式，技術底子來自 VP8 影片編碼，靜態圖部分用 VP8 的影格內壓縮（Intra-frame Compression）改寫而成。它支援有損與無損兩種模式、透明通道（Alpha Channel）、動畫，目標是一口氣取代 JPEG、PNG、GIF 三種格式。實務上同質量下，WebP 比 JPEG 小 25 至 35%，比 PNG 在透明圖場景小 20 至 40%。

AVIF 走的是另一條路。它是 AOMedia 聯盟在 2019 年定稿的格式，把 AV1 影片編解碼器的影格內壓縮抽出來當靜態圖規格。AV1 的目標是給影片串流時代用，壓縮效率本來就比 VP8 高一個世代，做成圖片後同樣受惠。同質量下，AVIF 比 JPEG 小 50% 上下，比 WebP 再小 20 至 30%；無損模式下 AVIF 也常常贏過 PNG。

差別不只在檔案大小。AVIF 原生支援 10 位元甚至 12 位元色深、廣色域（Wide Color Gamut）、高動態範圍（HDR），這些是 WebP 設計時沒考慮進去的需求。Hero Banner 用 AVIF 不只壓得更小，色彩也更乾淨。

代價是編碼成本。把同一張 4000 像素寬的照片壓成 WebP 與 AVIF，AVIF 的編碼時間在 libavif 預設速度下大約是 WebP 的 5 至 10 倍。批次處理整個媒體庫時，這個倍率會直接反映在伺服器負載與外掛轉檔的佇列長度上。

瀏覽器與 WordPress 原生支援現況

2026 年初的 caniuse 數據裡，WebP 全球瀏覽器覆蓋率約 96.4%，AVIF 約 93 至 95%。差距已經縮到個位數百分點，剩下的差異多半發生在企業內網 IE 殘留、老舊 Android Webview、特殊用途瀏覽器。下面這張表把兩種格式的關鍵支援節點放在一起看。

WordPress 6.5 把 AVIF 納入媒體庫上傳白名單後，後台介面已能直接上傳、自動產生縮圖、跑 srcset。前提是伺服器的影像處理函式庫支援它，PHP 8.1 以上、GD 函式庫或 ImageMagick 編譯時要帶 AVIF 旗標。許多共享主機到 2026 年仍預設沒開，事前用 phpinfo 或主機後台的 PHP 模組頁面確認，比上傳當下才看到錯誤訊息來得省力。

剩下那 3 至 7% 不支援 AVIF 的訪客怎麼辦，答案不是放棄 AVIF，而是用 picture 標籤做回退，這部分留到最後一節再展開。

ShortPixel、Imagify、EWWW 三套工具的定位差別

WordPress 雖然原生支援上傳 AVIF，但媒體庫已經堆滿 JPEG 的老站，不可能手動一張張重存。把舊圖批次轉成新格式、再依瀏覽器吐對應版本，要靠圖片優化外掛。2026 年市場上活躍度最高的三套，分別走不同路線。

• ShortPixel：雲端轉檔為主，原圖上傳後送到 ShortPixel API 處理，回傳 WebP 與 AVIF。壓縮品質在獨立測試中最穩定，AVIF 在免費方案就能本地落地（不必再買 CDN 套餐），對 JPEG 的壓縮率拉到 50 至 80% 區間。流量大的站要評估月配額與付費規模。
• Imagify：與 WP Rocket 同公司，後台 UI 走最簡路線，三個壓縮等級點下去就跑。AVIF 轉檔的實測壓縮率在 2026 年的多家測試中都拿到第一，但 API 配額計算稍嚴，搭配 WP Rocket 時的整合度是它最大的賣點。
• EWWW Image Optimizer：唯一主打本地優化的選項，可以完全不送圖到外部 API，把 GD 或 ImageMagick 在自家伺服器壓到底。對在意資料隱私、或月圖量超大不想被配額限制的站台很合理。但 AVIF 轉檔必須掛 Easy IO CDN（付費功能），這是它在 2026 年最常被點名的功能落差。

選哪一套不是看誰最強，而是看流量規模、隱私需求、是否已經買了 WP Rocket、伺服器能不能跑本地轉檔。同一個站台用三家不同工具，省下來的傳輸量級可能差不到 10%，但月費與維運心力可能差兩三倍。

三種典型情境的取捨建議

「該選 WebP 還是 AVIF」這個問題沒有單一答案，要看站台的圖片量、訪客結構、編輯流程。下面用三種常見的 WordPress 站型示範怎麼判斷。

靜態形象站

形象站、品牌官網、企業簡介這類，圖片總量通常落在 100 張以內，更新頻率低，Hero Banner 與作品集是視覺重點。這種站台適合直接走 AVIF 為主，因為圖少、轉檔的一次性成本可以一次吃掉，而 Hero Banner 用 AVIF 對 LCP 的改善最直接。

WebP 在這裡的角色是回退用，picture 標籤掛上去就好，不必為了那 3% 老瀏覽器再額外調品質。重點放在每張圖都壓到 80 至 100 KB 以內、寬度配合最大顯示尺寸，不要上傳 4000 寬卻只顯示 1200 寬。

電商站

電商與 WooCommerce 站的情境最複雜。商品圖動輒上千張，每張要有列表縮圖、商品頁主圖、放大圖三種尺寸，乘起來就是上萬張變體。批次把整批轉成 AVIF 的伺服器負擔，比形象站重一個數量級。

務實做法是 WebP 全面化、AVIF 留給 Hero 與重點頁。商品列表頁的縮圖跟分頁載入的次圖用 WebP 就夠了，反正每張本來就只有 30 至 80 KB，再省一輪能節省的絕對檔案量有限；首頁 Hero、品牌故事頁、活動專題頁的大圖才上 AVIF，這些頁面的 LCP 對轉換率敏感，多花的編碼時間成本效益最高。

部落格與內容站

部落格與媒體型網站，文章內圖是主力，每篇 5 至 15 張、發佈頻率高。這種站適合走「上傳即轉」的自動化流程，編輯端不必管格式，由外掛在背景把每張圖都轉成 WebP 與 AVIF 兩份。

格式優先序建議 AVIF 第一、WebP 第二、原檔當最後保險。文章圖大多是寬度 1200 上下的內文圖，AVIF 的壓縮優勢在這個尺寸最明顯，常常能從 WebP 的 80 KB 再壓到 40 KB 以下。搭配延遲載入（Lazy Load），下捲到第三屏才載第三屏的圖，整篇的初始載入量會跟著大幅下降。

picture 標籤回退與延遲載入怎麼配

把多種格式同時掛在頁面上，靠的是 HTML5 的 picture 標籤。瀏覽器會由上到下讀 source，挑第一個它認得的格式抓檔，最後 img 標籤是所有 source 都不支援時的保險。WordPress 主流圖片優化外掛開啟「重寫 HTML」選項後，會自動把 img 改寫成 picture 包覆結構，編輯端不必手動加。

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="675" loading="lazy">
</picture>

幾個容易漏掉的細節，值得在啟用後立刻檢查。img 標籤一定要保留 width 與 height 屬性，瀏覽器才能在圖檔還沒下載完前預留正確空間，避免 CLS 跳分。loading 屬性除了首屏的 Hero 與 Logo 之外，其餘都加 lazy；首屏的關鍵圖反而要加 fetchpriority=”high”，讓瀏覽器優先抓。延遲載入若是靠 JavaScript 外掛（而不是瀏覽器原生 loading），要確認它能正確處理 picture 結構，不少老外掛只認 img，會把 source 抓不到。

最後一個常見陷阱是 CDN 的快取金鑰。Cloudflare、BunnyCDN 預設不會依 Accept 標頭分開快取，當外掛伺服器端依照瀏覽器來吐不同格式時，邊緣節點會把第一個訪客的版本快取下來給後續所有人用，AVIF 就可能被送到 Safari 14 上。解法是讓外掛走 picture 標籤客戶端決定，或在 CDN 規則裡把 Vary: Accept 加進快取金鑰。

把這幾件事處理完，圖片這塊的速度紅利就吃滿了。剩下來的問題通常已經不是格式選錯，而是哪張圖根本不該放上去、或哪個尺寸根本沒必要做這麼大。回到圖片本身的編輯紀律，才是 webp avif 圖片壓縮 之外，下一輪優化的起點。