部署 WebP：品質設定、涵蓋率，以及通往 AVIF 的路
每種來源格式一個品質設定、3% 的瀏覽器缺口、零 CDN 異動，以及用 picture fallback 加入 AVIF 的里程碑計畫。
一種品質設定不適用所有來源
我們用兩種品質設定（q80 和 q95）跑完完整的實驗。兩組資料指向同一個結論。用一個全域 q 值不是最好的做法。 原因：同一個 q 對不同來源類型代表不同意義。
有損來源（JPEG、GIF）的細節有限。q95 時編碼器把位元組花在原圖根本沒有的細節上。節省幅度大幅下降，而且大小階梯（自動降級來讓輸出比輸入小的機制）頻繁觸發。
無損來源（PNG）對品質敏感。q95 時節省幅度仍然很大，因為原圖有完整的細節可壓。
數字說明一切：
| 轉換 | 建議 q | 大小縮減 (p50) | SSIM (p50) | 原因 |
|---|---|---|---|---|
| JPEG → WebP | q80 | 47.1% | 0.979 | q95 時節省降到 13.5%。大小階梯在 25 張中觸發 9 次。 |
| GIF → WebP | q80 | 51.0% | 0.980 | q95 時節省降到 10.7%。大小階梯在 25 張中觸發 10 次。 |
| PNG → WebP | q95 | 71.3% | 0.994 | q80 時節省升到 82.9% 但 SSIM 降到 0.982。PNG 值得留更高品質。 |
經驗法則： 有損來源用 q80，無損來源用 q95。在上傳時偵測來源格式，再選品質。
q（品質設定）是編碼器的旋鈕，0 到 100。越高保留越多細節，檔案越大。SSIM（結構相似度）衡量視覺接近程度，0 到 1。0.95 以上多數人看不出差別。
3% 涵蓋率缺口
硬替換代表只送 .webp，沒有 fallback。不支援 WebP 的瀏覽器會顯示破圖。那次曝光就丟了。
誰在 3% 缺口裡（caniuse 全球估計）：
- IE 11。 2022 年 6 月結束支援，但部分企業環境還在用。
- Safari 13 及更舊版本。 2019 年以前的 iOS 和 macOS 裝置。
上線前，先讀自己流量的 user-agent 分佈。你的受眾的真實缺口可以遠低於全球 3%。現在多數廣告流量跑在新版 Chrome 和 Safari 上，WebP 完整支援。
上線要改什麼
改動很小。只有圖片轉換服務需要一個新的匯出分支。
三個步驟：
- 在轉換服務加上 WebP 匯出。 目前匯出函式沒有 WebP 或 AVIF 分支，直接 fall through 到 JPEG。加上 WebP 的 case。
- libvips 原生支援 animated WebP。 不需要額外工具。（Animated AVIF 需要另一條 ffmpeg 路徑。細節見 Part 01。）
- 按來源類型設品質。 JPEG 和 GIF 用 q80。PNG 用 q95。在上傳時偵測來源格式。
CDN、負載平衡器、物件儲存的路由全部不動。.webp 檔案進同一個儲存桶，CDN 送它跟送 .jpg 一模一樣。不用改 CDN 設定，不用改路由規則，不用清快取。
下一步：通往 AVIF 的路
WebP 是里程碑 1（M1）。基準測試的資料支持再走兩步。每一步建立在前一步之上。
M2：<picture> fallback + 有條件的 AVIF
<picture> 元素按順序列出格式。瀏覽器選它支援的第一個。
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="...">
</picture>這個寫法有三個好處：
- 涵蓋率缺口降到 0。 每個瀏覽器都拿到它能解碼的格式。
- AVIF 只送給支援的裝置。 Chrome 85+、Firefox 93+、Safari 16.4+ 拿更小的 AVIF。其餘拿 WebP 或原始格式。
- 不會有破圖。 Fallback 是自動的，使用者看不到。
AVIF 壓得比 WebP 更小（見 Part 02），但解碼成本更高。只送給支援的裝置是穩妥的做法。
M3：CDN 格式協商
CDN 讀瀏覽器的 Accept 標頭，選最好的格式。標記維持一般的 <img> 標籤。CDN 設定用基礎設施即程式碼管理，加上協商規則是一次設定改動。
這是長期最乾淨的方案，但需要 CDN 層級的改動。M1 和 M2 先來。
延伸閱讀： 回到圖片格式基準測試總覽，或讀 Part 01：GIF 轉 Animated WebP 和 Part 02：WebP vs AVIF。
參考來源：