图片格式的收益边界：PNG → WebP → AVIF 实测

第一轮：按质量参数比，结论是错的#

最直接的做法是「WebP quality=80 vs AVIF quality=80」。实测下来 AVIF 反而更大（上表 q75 那一列已经能看出趋势，q80 更明显）。

原因很简单：两种编码器的 quality 不是一个标尺。WebP 的 80 与 AVIF 的 80 对应的视觉质量完全不同，直接比体积没有意义。

这一轮唯一有效的结论是：AVIF 的等视觉质量点大概在 q50~q60 附近，而不是 q75+。

第二轮：用 PSNR 对齐画质#

正确做法是先定义「什么算同画质」，再在那个点上比体积。我用 PSNR（峰值信噪比）当判据：

• 参考图 = 仓库里现成的 WebP（它本身已经是有损压缩过的，作为基准）；
• 对每张图用 AVIF 从 q40 到 q80 逐档编码，算它与参考图的 PSNR；
• 取第一个 PSNR ≥ 38 dB 的档位 —— 38 dB 大约是「并排看、放大到 100% 也看不出差别」的水平。

结果：

平均规律：文字/界面类截图省 35%~42%，照片类只省 17% 左右。 这很符合直觉：AVIF 的优势在大面积平滑渐变与照片，而截图里全是锐利的文字边缘，省不出那么多。

编码耗时方面，1400×900 一张图 WebP 约 113 ms、AVIF q60 约 144 ms（1.3 倍）。对构建期批量处理来说完全可以接受。

那为什么我还在用 WebP#

三个理由，按权重排：

1. 收益要看绝对值。 我站上单张图平均 70 KB（51 张 / 3.63 MB），省 35% 就是每张省 25 KB、全站省约 1.2 MB。而文章页一次只加载 3~5 张图 —— 单页实际省下 100 KB 左右。这 100 KB 值得做，但不值得为它牺牲”一套格式、一个脚本”的简单性。

2. 兼容性还差一点。 AVIF 在 Chrome 85+、Firefox 93+、Safari 16.4+ 才支持。2023 年之后的浏览器都没问题，但没有一个通用格式做不到的兜底：老浏览器打开就是空白图。

3. 一部分图是从截图直接来的。 截图（大量锐利文字）恰好是 AVIF 收益最低的一类，而它是我最主要的图源。

什么时候值得上 AVIF#

如果你符合下面两条以上，就该上：

• 站点图片总量大（几十 MB 以上），或单张图很大（> 500 KB）；
• 图片以照片/插画为主，而不是文字截图；
• 访客主要在移动网络；
• 已经有 <picture> 或图片组件，能同时输出两种格式。

写法就是标准的 <picture> 回退：

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

浏览器会挑它支持的第一个格式，两种都压好、谁支持谁用，这才是不牺牲兼容性的做法。

一个容易被忽略的对比维度#

除了体积，还有两个数字值得一起看：

解码耗时这一项常被忽略：AVIF 的解码比 WebP 重，在低端手机上首屏图片渲染可能反而更慢。省下的字节要能抵过解码代价，才算真的赚。

小结#

三条可以直接用：

1. 别按质量参数比：WebP 80 与 AVIF 80 不是同一个东西，要先定义”同画质”（我用 PSNR ≥ 38 dB）；
2. 截图与照片要分开看：截图省 35%~40%，照片只省 15%~20%；
3. 决定因素是绝对字节数：单页省 100 KB 值得做，但为它引入两套格式、两套脚本，就不一定了。

我目前的结论是：继续用 WebP 单格式，等图片量再涨或者需要面向移动网络时，再切到 <picture> + 双格式。到时候这篇文章里的数字可以直接拿来算收益。

每一步怎么执行写在文章配图流水线里，两篇可以对照着看。

封面图该用多大的图、要不要用随机图接口，见随机图当封面那篇。