从 JPEG 到 AVIF：Web 图片格式的三十年演进

Web 图片压缩的历史是一部收益递减与生态滞后的编年史。JPEG 诞生于 1992 年，根据 HTTP Archive 2025 年 Web Almanac 报告，它至今仍占据全网图片的 60% 以上——一个比大多数使用它的开发者还老的格式。PNG 在 1996 年问世，带来了无损压缩和 Alpha 透明通道，但文件体积使其在摄影场景中几乎没有用武之地。Google 于 2010 年开源 WebP，宣称同等画质下比 JPEG 小 25-35%，但直到 2020 年 Safari 14 发布，WebP 才真正实现全浏览器覆盖——整整十年。每一个新格式都在重复同一轨迹：技术先进性发布 → 部分浏览器支持 → 生态缓慢跟进 → 普及时先驱者已转向下一个格式。

AVIF（AV1 Image File Format）由开放媒体联盟于 2019 年发布，底层编码与 Netflix、YouTube 使用的 AV1 视频 Codec 同源。它将压缩效率推到新高度：同等感知质量下比 JPEG 小约 50%、比 WebP 小约 20%。一张 300KB 的商品主图转为 AVIF 后可降至 140KB，肉眼几乎看不出差异。但 AVIF 也在走 WebP 走过的路。2026 年工程团队面对的问题不是"要不要用 AVIF"——带宽节省的数据摆在那里——而是"如何在部署 AVIF 的同时，确保不支持它的浏览器用户不会看到裂图"。

浏览器支持现状：AVIF 在哪里能用，在哪里会裂

截至 2026 年 7 月，AVIF 在 Chrome 85+、Firefox 93+、Edge 92+ 和 Safari 16.4+ 中获得原生支持。Can I Use 的聚合数据显示全球覆盖率约为桌面端 94%、移动端 92%。剩余 6-8% 并非随机分布，而是集中在几个可预见的用户群体中。

最大的缺口在 Safari 16.4 以下版本。该版本随 macOS Ventura 于 2023 年 3 月发布，运行 macOS Monterey 及更早系统的设备无法升级到 Safari 16.0 以上，永久无法解码 AVIF。Apple 在 WWDC 2026 公布的数据显示，约 8% 的活跃 iPhone 仍在运行 iOS 15 或更早版本——这些设备支持 WebP 但不支持 AVIF。对电商和媒体类站点而言，这部分用户的图片会直接裂开。第二个缺口在安卓 WebView：小米和 Realme 的低端设备上，2024 年以前的 WebView 版本在遇到 AVIF <source> 标签时不是优雅降级而是直接崩溃。此外，国内场景还有一层特殊问题：微信内置浏览器（X5 内核）在部分安卓版本上对 AVIF 的支持不稳定，UC 浏览器和 QQ 浏览器的旧版内核同样存在兼容问题。

CDN 层面也有隐患。阿里云 OSS 和腾讯云 COS 的图片处理服务在默认配置下会进行实时转码，部分场景下会将 AVIF 文件的 Content-Type 头改为 image/jpeg。Chrome 和 Firefox 能容忍这种 MIME 类型不匹配，但 Safari 直接拒绝渲染——图片位置变成空白。这是服务端配置问题，客户端的回退链无法解决，部署 AVIF 前必须先验证 CDN 的实际行为。

三级回退链：AVIF → WebP → JPEG

HTML <picture> 元素是格式回退的标准方案。浏览器按文档顺序逐个评估 <source> 元素，渲染第一个能解码的格式，如果都不支持则回退到 <img> 元素：

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="商品主图" width="1200" height="800">
</picture>

这条三级链几乎覆盖所有在用浏览器。如果跳过 WebP 层直接从 AVIF 回退到 JPEG，Safari 15 用户——支持 WebP 但不支持 AVIF——就会下载更大的 JPEG 而非优化后的 WebP。以一张 300KB 的图片为例，每个受影响用户每次请求多消耗约 90KB 流量。在大流量场景下，多生成一个 WebP 变体的存储成本远低于省下的带宽。性能开销几乎为零：现代浏览器在发起网络请求前就完成了 <picture> 元素的源选择，不会重复下载多种格式。

AVIF 之后是什么——构建可扩展的图片管线

JPEG XL 曾被视为 AVIF 的继任者，但 Chrome 在 2023 年搁置了对其的支持，目前仍是小众实验格式，没有进入主流浏览器的路径。AVIF 作为下一代图片格式的事实标准地位至少能维持到 2027 年。Google 在 2026 年 I/O 上提到了 AV2 编解码器的早期研究，可能在未来产生 AVIF 的继任者，但尚未公布时间线，AV2 距离稳定规范至少还有三年。

对工程团队的启示是：构建格式无关的图片管线，而非将 AVIF 生成硬编码到单一构建步骤中。如果工具链只会输出 AVIF，未来切换到新格式时就得重写整层。一个能接受任意输入格式、输出可配置变体（AVIF、WebP、JPEG 及未来格式）的管线，才能在不改架构的前提下适配演进。需要注意的边界情况：AVIF 并非总是最小。对于大面积纯色区域的图片——图标、插画、Logo——AV1 编码器的复杂度开销可能使 AVIF 文件反而比 WebP 更大。"一刀切转 AVIF"的策略不如按图逐张测量、选最优格式的策略。

落地清单

第一步，盘点现有图片资产：区分摄影类内容（AVIF 优势明显）和纯色图形类内容（WebP 或 PNG 可能更优）。第二步，搭建构建时管线，为每张图片生成 AVIF、WebP、JPEG 三种变体。第三步，在模板或组件库中实现 <picture> 回退链。第四步，验证 CDN 配置——确保 Content-Type 头不被篡改，实时转码不干扰预生成变体。第五步，通过分析平台监控实际格式分发情况，确认多数用户确实收到了 AVIF 而非静默回退到 JPEG。对于需要批量转换已有图片目录的团队，Image Toolbox 网页优化器可以同时生成三种格式变体并输出完整的 <picture> 标签，同时标记 AVIF 反而比 WebP 更大的图片，帮助你按图决策而非一刀切。Web 终于在告别 JPEG-only 时代，但只有先搭好回退基础设施，AVIF 的带宽红利才能真正落到用户头上。