圖片格式基準測試：跑完 5,625 次，WebP 勝出

目標：更快繪製，不只是更小的檔案

從請求到繪製之間的每一毫秒，都是使用者盯著空白的一毫秒。在中階手機搭配慢速 3G 時，這個間隔決定圖片能不能顯示出來。

我們想回答一個問題。換一種格式，能讓投放體驗明顯變好嗎？ 不是「能省多少位元組」，而是使用者能不能更快看到圖片、在更多裝置上看到。

圖片更快到達螢幕時，三件事會改善：

1. 圖片更早繪製。 使用者更早看到它。在廣告投放中，廣告在使用者滑走前就顯示出來。
2. 慢速網路不再逾時。 原本在 slow 3G 上要 900 ms 的下載變成 530 ms，圖片來得及到達。
3. 弱 CPU 跟得上。 低電量模式的手機會降低 CPU 速度。更輕的解碼代表圖片仍能在下一幀前完成。

CDN 費用也會下降，但那是附帶效果，不是目標。

格式現況：我們今天送什麼，市場上有什麼

目前投放三種格式：JPEG（照片）、GIF（動畫）、PNG（透明背景）。兩種現代替代方案：

• WebP（Google，2010 年）。有損與無損模式。Animated WebP 取代 GIF。瀏覽器支援度：全球 97%。
• AVIF（AOM，2019 年）。基於 AV1 影片編碼。壓縮率上限高於 WebP。瀏覽器支援度：95%。

取捨不只是「誰壓得更小」。投放時有三個軸線要考量：

這個系列會用到的名詞

這個系列用到幾個來自網頁效能和圖片編碼的指標。每個名詞在各篇第一次出現時會再附上行內定義。這張表是參考用的。

名詞	白話解釋
LCP	Largest Contentful Paint。使用者看到圖片的那一刻。本系列的主要速度指標。
解碼時間	CPU 把下載完的位元組轉成像素的工作量。壓縮越重，解碼越花力氣。
SSIM	結構相似度，0 到 1。轉換後的圖跟原圖有多像。0.95 以上多數人看不出差別。
TTFB	Time To First Byte。伺服器多快開始回傳。圖片格式不影響這個指標。
CPU 節流	Chrome DevTools 把 CPU 速度降低 N 倍來模擬弱手機。1x = 桌機。4x = 中階。6x = 低階。
Cold / Warm	CDN 是否已經有這張檔案？Warm = 有，直接送。Cold = 沒有，要先去 origin 拿。
q（品質）	編碼器的品質旋鈕，0 到 100。越高保留越多細節，檔案越大。
CDP	Chrome DevTools Protocol。我們用來程式化控制 Chrome 的介面。

實驗機器：CDP 如何自動化 6,075 次測量

75 張圖 × 3 種格式 × 3 種 CPU 等級 × 5 次重複 = 手動要按 3,375 下。我們改用自動化管線。

核心想法：每次測量的步驟都一樣，而 CDP 讓這些步驟可以用程式驅動。 一個測試頁面載入一張圖、收集指標、結束。Playwright（無頭 Chrome）用 CDP 控制四個變數，把同一個頁面跑上千次：

• CPU 節流，透過 Emulation.setCPUThrottlingRate。三個等級：1x（桌機）、4x（中階手機）、6x（低階手機）。
• 網路模擬，透過 Network.emulateNetworkConditions。兩種情境：fast 4G（9 Mbps、60 ms）和 slow 3G（1.6 Mbps、300 ms）。
• 每次測量都開新的無痕視窗。 達成快取隔離，不用重啟瀏覽器。
• 指標收集來自四個瀏覽器 API。Element Timing 記錄載入和繪製時間戳。Resource Timing 記錄下載時間。LCP observer 記錄繪製完成時間。img.decode() 記錄純 CPU 解碼成本。

同一個測試頁面服務全部三個實驗。只有被控制的變數不同：

實驗 A 回答：「不算網路，每種格式的純 CPU 成本是多少？」在 localhost 上跑，下載時間趨近零。

實驗 A2 回答：「在受限網路下，省下的位元組能否抵消解碼成本？」在 localhost 加上網路節流。

實驗 B 回答：「走完真正的 CDN，哪種格式繪製最快？」走正式環境的路徑，每次記錄 cold/warm 快取狀態。

統計驗證用的是 Wilcoxon signed-rank 配對檢定，跨全部 75 張圖。這是無母數檢定，不假設資料服從常態分佈。

主要結果（品質 q80，中位數）

75 張正式環境圖片：25 張 JPEG、25 張 GIF、25 張 PNG。像素大小從 200x200 到 1200x627。

整體壓縮

來源格式	WebP 節省 (p50)	WebP SSIM	AVIF 節省 (p50)	AVIF SSIM
JPEG	47.1%	0.979	38.2%	0.986
GIF	51.0%	0.980	54.0%	0.994
PNG	82.9%	0.982	81.0%	0.992

在相同品質設定下，WebP 壓 JPEG 和 PNG 的幅度大於 AVIF。AVIF 壓 GIF 稍多，差距 3 個百分點。

解碼時間（CPU 把位元組轉成像素的成本）

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

在低階手機上，WebP 多花 1 ms 解碼。AVIF 多花 29.6 ms。這個差距在真實裝置上很重要。低電量模式的手機用同樣的方式降低 CPU 速度，每多一毫秒的解碼都在拉長使用者的等待。

合計：slow 3G + 中階手機的下載加解碼

格式	最小值 (ms)	中位數 (ms)	最大值 (ms)
原始格式	438	939	6,777
WebP	410	534	1,466
AVIF	413	547	1,406

中位數圖片換成 WebP 後提早 405 ms 繪製完成，快了 43%。AVIF 在這裡接近 WebP，因為更小的檔案抵消了更重的解碼。最大值欄位顯示各格式的最差情況，WebP 和 AVIF 接近，但中位數 WebP 更好。

更細的拆解（按來源格式、按 CPU 等級、按網路情境）在 Part 02：WebP vs AVIF。

結論

把所有 GIF 換成 animated WebP。JPEG 和 PNG 轉 WebP 作為第二批。AVIF 之後再上，放在 <picture> fallback 後面。

轉換	建議	根據
GIF 轉 animated WebP	全部替換	小 51%，動畫完整，25/25 通過完整性檢查
JPEG 轉 WebP	第二批	小 47%，SSIM 0.979，編碼速度快 AVIF 24 倍
PNG 轉 WebP	第二批	小 83%，SSIM 0.982
AVIF	下一個里程碑 (M2)	壓縮率更高，但低階裝置解碼 32 ms，涵蓋率 95%
品質設定	JPEG/GIF 用 q80，PNG 用 q95	有損來源的細節有限。見 Part 03。

帶走的東西

1. 用自己的流量做基準測試。 公開的比較用的是合成測試圖。你的正式環境圖片有不同的大小分佈和裝置組成。用自己的資料測。
2. 解碼成本跟檔案大小一樣重要。 AVIF 壓得更小，但在低階裝置上的解碼時間（6x 節流下中位數 31.9 ms）會吃掉省下的下載時間。壓縮率最高的格式不一定是繪製最快的。
3. CDP 把抽查變成數千次測量。 一個 Playwright 腳本加一個測試頁面，產出 6,075 個資料點。沒有 CDP 自動化，這個基準測試要花好幾週。
4. 涵蓋率不足時，直接替換會讓部分使用者看不到圖。 WebP 支援度 97%，代表 3% 的瀏覽器會顯示破圖。先讀自己的流量資料。<picture> 元素可以補上這個缺口。這就是為什麼 AVIF（95%）放在 M2。

接下來讀什麼

這個系列有三篇深入文章，每篇都帶完整的資料表和行內圖表。

• Part 01：GIF 轉 Animated WebP：省最多的一刀。大小縮減、動畫完整性、libvips 的 animated AVIF 坑，以及編碼時間。
• Part 02：WebP vs AVIF：正面對決。檔案大小、各 CPU 等級的解碼時間、各網路情境的下載時間，以及讓 WebP 勝出的五個標準。
• Part 03：部署 WebP：品質、涵蓋率，以及通往 AVIF 的路。每種來源格式一個品質設定、3% 缺口，以及 M2 路線圖。

格式基礎知識（JPEG 和 PNG 有什麼不同、動畫如何以 page-strip 運作、有損和無損），見裁切、縮放、填滿：圖片處理系列。廣告投放讓圖片格式的優先序翻轉那篇是「格式怎麼運作」和「如何為投放做基準測試」之間的橋樑。

---

參考來源：

• https://caniuse.com/webp（WebP 瀏覽器支援度，97%）
• https://caniuse.com/avif（AVIF 瀏覽器支援度，95%）
• https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4（Netflix AVIF 評估）
• https://web.dev/articles/choose-the-right-image-format（web.dev 格式指南）
• https://developer.chrome.com/docs/devtools/device-mode#cpu（Chrome DevTools CPU 節流）