为了在 4G 网络下实现秒开，我实测了 AVIF 和 WebP 的压缩极限

最近在优化页面加载速度时，我产生了一次强迫症发作。在一个典型的电商详情页中，如果包含 6 张高清产品图，使用传统的 JPEG 格式可能会导致页面体积增加 3MB 左右，这在弱网环境下直接决定了用户的跳出率。为了找到最优解，我针对 AVIF、WebP 和 JPEG 做了 100 张图片的压力测试（包含 50 张实拍照片和 50 张 UI 截图），结果揭示了这三种格式在实际工程中的残酷差异。

首先看最核心的体积表现。在视觉观感几乎没有区别的前提下，压缩率的梯度非常明显。我测试了一张 2MB 的 JPEG 原图，将其转换为 WebP 后体积降至 480KB，而进一步转为 AVIF 后，体积直接掉到了 310KB。这意味着在处理实拍照片类素材时，AVIF 是绝对的压缩之王，其体积比 JPEG 缩减了 60% 以上，且明显优于 WebP。

但如果处理的是截图或设计稿（PNG 源），情况就变得复杂了。如果你追求像素级的精准，尤其是带有细小文字的 UI 界面，无损压缩的 PNG 依然是最稳妥的选择。当然，如果只是普通的插图，使用 WebP 并在质量参数设为 q80 时，体积能够缩减约 7 倍，这在大多数场景下已经足够。

然而，AVIF 并非没有缺陷，它最致命的痛点在于编码速度。在我的实测中，单张图片的压缩耗时呈现出巨大的阶梯差：JPEG 仅需 0.3s，而 AVIF 竟然需要 2.5s。如果进行大批量处理，AVIF 的耗时是 WebP 的 3 倍，更是 JPEG 的 8 倍。

这个性能差距直接决定了在实际开发中的选择逻辑。如果你是在开发一个静态网站，所有的图片在构建阶段（Build time）就已经预处理完成，那么毫不犹豫地选择 AVIF，因为你只需要支付一次编码成本，而所有访问用户都能享受到极速加载。但如果你在处理用户实时上传的 UGC 内容，WebP 才是更合理的平衡点，否则高昂的编码耗时会给服务器 CPU 带来巨大的压力，甚至导致上传接口超时。

为了在极致性能和兼容性之间取得平衡，我建议不要在单一格式中死磕，而是利用 HTML 的 <picture> 标签构建一套多格式回退机制。通过这种方式，浏览器会根据自身的支持情况，优先加载最轻量且支持的格式，如果都不支持，最后才会 fallback 到 JPEG。

具体实现代码如下：

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description">
</picture>

总结这次实测的结论：如果你的项目追求极致的体积压缩且能接受较慢的预处理速度，AVIF 是首选；如果你需要兼顾兼容性与编码效率，WebP 是目前最稳妥的中间地带。