图片格式升级常常被讨论成一句很简单的话：
“把 JPEG 和 PNG 换成 AVIF 就好了。”
现实没有这么直接。
格式升级真正影响的是一整条交付链路：
- 资源生成成本
- 浏览器兼容性
- 回退方案
- CDN 缓存键
- 编辑和设计同学的素材交付方式
所以 AVIF 和 JXL 的讨论，核心不只是压缩率，而是上线边界是否清晰。
AVIF 和 JXL 解决的是不同阶段的问题
AVIF 已经成为很多团队讨论的默认新格式，因为它在高压缩比场景下确实很强，尤其适合：
- 首页大图
- 内容站封面图
- 营销页视觉图
而 JXL 的价值更偏向于：
- 高保真图片工作流
- 有明显渐进解码和编码效率诉求的团队
- 希望统一未来资产策略的长期规划
如果不区分使用场景，只用“谁更先进”来选型，结论往往没有执行价值。
格式升级要先过三道判断
更实用的决策顺序通常是：
- 目标浏览器覆盖是否允许
- 现有图像处理链路能否稳定生成
- 回退策略是否已经设计好
如果只看实验室压缩效果，而没有过这三道判断，线上资源链路很容易在某个弱点上出问题。
交付链路比格式本身更值得重视
很多团队不是不会生成 AVIF，而是生成之后交付不稳：
- 同一张图只生成了新格式，没有生成回退格式
- 不同环境图片命名规则不一致
- CDN 上缓存了错误内容协商结果
- 设计侧无法预览最终线上版本
更稳的做法，是把图片格式升级纳入统一资源流水线，而不是在页面里零散手写。
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="product hero" loading="lazy">
</picture>
这段结构本身不复杂，难点在于如何让生成、命名、缓存和回退都保持一致。
回退策略要从用户设备出发，而不是从工程师视角出发
用户不会在意你是否用了最新图片格式，他只会感受到：
- 打开是否快
- 图片是否清晰
- 是否出现空白或加载失败
因此回退策略至少应该覆盖：
- 浏览器不支持新格式时的替代资源
- 首图与非首图的不同优先级
- 高分辨率设备与普通设备的资源分层
如果回退策略只是“保留一个旧格式文件”，但没有接入真实页面结构，风险依然存在。
常见失败案例：压缩率很好，但线上体验并没有变好
这类项目常见的问题包括：
- 编码时间过长，构建链路变慢
- CDN 命中率下降，抵消了压缩收益
- 重要图片没有被正确预加载
- 图片质量参数设置不合理，导致视觉劣化
最后得到的是漂亮的实验报告，而不是稳定的体验提升。
一个更稳的升级方法
推荐按以下顺序推进：
- 先挑高流量页面上的少量关键图片试点
- 同步生成 AVIF、WebP 与原始回退格式
- 观察 LCP、带宽成本和构建时间变化
- 再决定是否扩大到全站资源流水线
如果直接一次性替换全站格式，团队很难定位问题究竟出在浏览器兼容、编码参数还是缓存策略。
一份可直接复用的检查清单
- 是否先确认了目标浏览器覆盖和业务场景
- 是否把新格式生成纳入统一资源流水线
- 是否为关键图片补齐了多格式回退方案
- 是否同时观察压缩收益、构建成本和 CDN 命中率
- 是否先通过小范围试点验证，再决定是否全站推广
总结
AVIF 与 JXL 的价值，不只是让图片更小，而是推动图片交付链路升级。只要兼容范围、生成流程、缓存策略和回退方案一起设计，格式演进才会真正带来稳定收益。
进一步阅读：
