JPEG XL 终于进了所有主流浏览器，但它没赢过 AVIF

结论先摆出来

JPEG XL 这个格式的命运一直很曲折：技术指标好看，浏览器支持却拖了很多年。到 2026 年 10 月，它总算在所有主流浏览器里落地了。前端圈的老牌工程师 Jake Archibald 趁机做了一轮细致对比，结论对期待「新格式一统江湖」的人不太友好。

对网页上的有损照片，AVIF 几乎总是产出更小的文件。默认压缩强度下，最优的 JPEG XL 结果通常比同画质的 AVIF 大 15%–25%；把强度拉满，差距缩小到 6%–20%。也存在 JPEG XL 反超甚至领先的个例，所以真要抠某张图，两个都试一遍是值得的。

对截图和插画，AVIF 明显更好：同等画质的 JPEG XL 在默认强度下大 30%–90%，拉满强度后大 20%–70%。这里还有个反直觉的点——这类图不必非要用无损格式，有损 AVIF 处理得已经足够好。

对带透明的图，AVIF 优势最大：libjxl 版本在默认强度下大 31%–44%，最高强度下大 61%–70%；另一个编码器 jixel 干脆把透明通道按无损存，文件直接是 AVIF 的两到三倍。

编码器本身是个变量

这篇文章里最值得记住的一条，是编码器的影响不亚于格式。JPEG XL 有个较新的编码器叫 jixel，通常比官方的 libjxl 产出更小——除非图里有细节丰富的透明区域。但作者也发现，有些情况下 jixel 明显是在「刷指标」：数字更漂亮了，肉眼一看却更差。

速度上也有取舍。整体算上文件体积，AVIF 编码更快、内存更省；jixel 单看编码速度比 AVIF 快、内存也更省，但它产出的文件通常大得多，综合下来还是 AVIF 更划算。解码则是 AVIF 明确更快，JPEG XL 在中等画质下要花两到三倍时间，只有在很高质量的场景，Chrome 才偶尔能把 JPEG XL 解得比 AVIF 快。

还有一个容易踩的坑：提高压缩强度对 AVIF 和 jixel 有意义，对 libjxl 基本没意义。libjxl 的高强度档又慢又吃内存，画质几乎没提升，有时文件反而更大。

一个被滥用的默认值

作者专门点了 AVIF 的 4:2:0 模式（色彩分辨率减半）。很多工具把它当默认值，实际上它很少真的减小体积，反而让高画质更难达到，只是编解码快一点。他的建议很直接：没时间两种都测的话，就用 4:4:4。

另外，所有编码器的画质参数都还算可靠，同一个质量值出来的效果比较稳定。

怎么落到自己的站点上

看完这一圈，正确的结论不是「把网站图片全换成 AVIF」，而是按场景分工：照片类素材走 AVIF，界面截图和插画也走 AVIF，带透明的图标优先 SVG 或 AVIF，JPEG XL 留给那些 AVIF 明显吃亏的个例。同时别忘了最有效的一招其实最老：按显示尺寸出图，别拿一张 3000 像素的原图去填 600 像素的位置。

对做静态站交付的小团队，这件事的现实意义在于：图片体积往往是一个站点最大的性能负债，而它又最容易被忽略。一套固定的出图规范——统一宽度档位、统一质量参数、统一格式策略——比任何框架优化都见效快。真正该记住的不是哪个格式赢了，而是「默认值不可信，得按场景测」。