现代格式能省下实实在在的带宽：同等画质下 WebP 通常比 JPEG 小 25–35%，AVIF 往往在此基础上再小 20–30%。问题在于如何在不影响老客户端的前提下提供它们。

方案 A：基于标记（picture + type）

用 picture 元素，内含声明 MIME 类型的 source 子元素，效率最高的排最前，最后用一个普通 img 携带 JPEG 作为通用兜底。

工作机制：浏览器按顺序遍历 source，取它支持的第一个类型。它不会比较文件大小，所以排序是你的决定，而不是浏览器替你做的优化。

优点：显式、静态托管即可、无需服务端逻辑、易于推理和调试。 缺点：标记冗长，且每张图都需要生成并提交/构建多个文件。

方案 B：服务端内容协商

服务器读取浏览器的 Accept 头，从同一个 URL 返回 AVIF、WebP 或 JPEG。

优点：HTML 保持简洁——一个 img、一个 src。缓存和 CDN 图片转换服务通常能自动完成。 缺点：必须正确处理 Vary: Accept，否则缓存会把错误的格式发给错误的客户端，这是个相当难查的 bug。

多数 CDN 和图片服务把这件事做得很好。如果你在用，优先选它；如果是静态托管，就用标记方案。

AVIF 值得吗

  • 压缩率：通常是现有最好的，在低码率、渐变和大面积纯色上尤其突出。
  • 编码耗时：显著慢于 JPEG/WebP。对于要处理上千张图的构建步骤，这很要紧；对于几张首屏图，无所谓。
  • 兼容性：当前浏览器支持广泛，但老设备和部分应用内网页视图并不通用，所以要保留回退。
  • 边界情况：低质量设置下，AVIF 可能过度平滑细节和颗粒。摄影作品集请在 100% 下对比，而不是只看字节数。

一个合理的策略：高流量页面和首屏图用 AVIF + WebP + JPEG，其余用 WebP + JPEG。

排序规则

永远把效率最高的放最前：AVIF、WebP、然后是 img 兜底。顺序反了，支持 WebP 的浏览器会欣然取用 WebP，永远看不到 AVIF。

实用注意

  • 各格式的质量参数要分别设定。 WebP 质量 75 与 JPEG 质量 75 在观感上并不等价；要对比输出结果，而不是把数字跨格式照搬。
  • 透明：WebP 和 AVIF 都支持 Alpha，所以只有极老的客户端才需要 PNG 兜底。
  • 能从原图编码就不要从已经有损的 JPEG 转码，重新编码会叠加伪影。
  • 衡量收益。 为本来就很小的图片生成三种格式，是在为微不足道的收益浪费构建时间——先把力气花在最大的那些文件上。