我的流量报表里有组数字一直很扎眼：每个月 60% 的流量都是图片，图片里 90% 都是 JPEG。如果每张图小 40%，一个月能省下多少带宽费？答案是让我连夜查资料的数字。
这篇文章就是我查完资料、做完实测之后的结论。数据分两种：权威来源（MDN、caniuse）和我自己跑的实测（同一张照片，三种格式，四个质量档，一毫秒一毫秒计时）。不拍脑袋，全部摆数据。
先认识一下这三个家伙。
JPEG，1992 年出生。 三十多年前为模拟照片时代设计的格式。用的是有损压缩里的 DCT（离散余弦变换）——把图像切成 8×8 的小块，丢掉人眼不敏感的高频细节。设计目标是"看着差不多就行"，当年做到了，今天看就是两个硬伤：不支持透明（一张带透明背景的图，JPEG 只能给你白底）；有损痕迹明显（低质量下那种方格子伪影，放大就露馅）。
WebP，2010 年 Google 出品。 从 VP8 视频编码里借来的技术，比 JPEG 年轻一代。同样是有损，但压缩算法更聪明：支持透明通道（代替 PNG 的活）、支持动画（代替 GIF 的活）、压缩率比 JPEG 高 25%~35%（MDN 数据）——同质量下，WebP 就是比 JPEG 小三分之一。
AVIF，2019 年由开放媒体联盟（AOMedia）推出。 从 AV1 视频编码里派生，是最年轻也最激进的格式。压缩率比 JPEG 高约 50%，比 WebP 再省 20% 左右（MDN 引用的对比数据），还支持 HDR、10-bit 色深、透明、动画。听着是完美答案？别急，后面有两个大坑。
上面这张是我做测试用的实拍照片（2000×1500）。下面所有数据都是拿它跑出来的，不是编的。
我用 Python + Pillow 把这张照片分别编码成 JPEG / WebP / AVIF，各跑了四个质量档（q40 / q60 / q80 / q100），记录体积：
| 质量档 | JPEG | WebP | AVIF |
|---|---|---|---|
| q40 | 170 KB | 94 KB | 69 KB |
| q60 | 277 KB | 129 KB | 168 KB |
| q80 | 320 KB | 195 KB | 266 KB |
| q100 | 930 KB | 606 KB | 1116 KB |
看图说话，三个结论：
第一，WebP 在中高质量区间（q60~q80）最省。 q60 时 WebP 是 129KB，JPEG 是 277KB——直接省 53%，而视觉上几乎分不出区别。这个区间是网页图片的主战场（缩略图、列表图、文章配图都在这个质量范围），所以 WebP 是大多数场景的最优解。
第二，AVIF 在低质量区间（q40）极致小。 69KB，比 JPEG 的 170KB 小 59%。如果你有大量"只展示、不细看"的图（比如瀑布流的占位缩略图），AVIF 能压到离谱的小。
第三，AVIF 的 q 参数和 JPEG/WebP 不是一回事。 注意 q100：AVIF 1116KB，比 JPEG 的 930KB 还大。这不是 AVIF 差，是它的质量参数语义完全不同——同 q 值不能直接横向比，AVIF 的高质量档追求的是"无损级保真"，体积自然爆炸。所以选型时别拿 q 值当统一标尺，要看"目标体积 + 视觉验收"。
把四个质量档连成折线更直观：三者的体积都随质量上升，但 WebP 的曲线整体压在 JPEG 下方（省），AVIF 在低质量区最低、高质量区反而翘起来。选格式不是选"哪个格式好"，是选"哪个格式在你的质量区间最划算"。
数据归数据，我还是怕"压缩后没法看"。所以我把 q80 的三张图都导了出来，尺寸一样（600px），你直接看：
同质量档下：JPEG 46KB、WebP 29KB、AVIF 40KB。放大看局部，WebP 和 JPEG 的差异要靠仔细找——树叶的纹理 WebP 略锐，JPEG 在天空过渡带有一点点色带；AVIF 在这个质量档反而没占到便宜（q 语义问题，前面说过）。结论很实在：网页上 99% 的场景，WebP q80 的观感 ≈ JPEG q80，但体积省 37%。这 37% 累计到一个月，就是实打实的带宽钱和首屏速度。
数据再好看，浏览器不支持全是白搭。查了 caniuse 2026 年 8 月的全球数据：
93.5% 看着挺高，但那 6.5% 里可能就有你的目标用户——比如还在用旧 iOS、某些国产浏览器内置内核、或者公司网络环境里的旧浏览器。图片显示不出来，比图片大 30% 严重得多。
所以正确的做法不是"选一个格式全站换"，而是用 <picture> 元素做多格式回退：
<picture>
<source type="image/avif" srcset="photo.avif" />
<source type="image/webp" srcset="photo.webp" />
<img src="photo.jpg" alt="照片" />
</picture>
浏览器按顺序选第一个能解码的格式：支持 AVIF 的用 AVIF，不支持的退回 WebP，再不行用 JPEG。渐进增强的教科书写法——支持的浏览器享受最小体积，老浏览器兜底能看。如果你用 Vite/Vue，这种写法配合构建插件可以自动生成三套图，零手工。
这里还有个进阶玩法：CDN 内容协商。很多 CDN（Cloudinary、Cloudflare Images、腾讯云数据万象）支持 Accept 头协商——浏览器发请求时带上 Accept: image/avif,image/webp，CDN 根据请求头自动返回对应格式，前端只需要一个 URL，格式分发完全交给 CDN。源图存一份，各格式按需生成。适合流量大、不想维护 <picture> 标签的团队。缺点是多一层 CDN 依赖，回源没协商时要注意兜底。<picture> 标签和 CDN 协商二选一就行，别两个都上——那等于给浏览器发了三份格式的 URL，反而绕。
体积省了，但编码呢？我顺手记了三种格式的编码耗时（PIL 实测，同一张照片，毫秒级）：
这个数字意味着什么？如果你在浏览器端实时把用户上传的图片转 WebP/AVIF，用户要等半秒甚至更久——上传体验直接崩。所以行业标准做法是预生成：图片上传到服务器/对象存储后，后台异步生成各格式各尺寸的派生图，用户列表里拿到的永远是现成的缩略图。
这个项目就是这么干的。上传走 COS（腾讯云对象存储），一条命令搞定派生：
// COS imageMogr2：缩到 1024px 内 + 转 WebP + 控质量
String rule = String.format(
"imageMogr2/thumbnail/1024x1024>/format/webp/quality/%d", quality);
8MB 的原图，上传后 COS 异步生成一张 128KB 的 WebP 缩略图，存进 thumbnailUrl 字段，列表页全加载缩略图——懒加载 + 缩略图 + WebP 三件套（上篇写过），首屏体积直接降两个数量级。用户上传的时候完全无感，因为编码发生在后台，不在他的等待时间里。
JPEG 有个 WebP/AVIF 都没有的特性：渐进式渲染（progressive）。渐进式 JPEG 加载时会先显示一张模糊的全图，再逐步变清晰——用户感觉"图在慢慢变清楚"，心理上更快。
WebP 和 AVIF 目前都不支持渐进式。大图（比如详情页的原图）用 WebP/AVIF，用户会看到"整块图突然跳出来"——加载完成前是一片空白，加载完成后整张弹出。在慢网络上，这个差异很直观：渐进式 JPEG 前三秒能看出"图的内容"，WebP/AVIF 前三秒只有白块。
所以我的建议是分场景：列表图/缩略图用 WebP（体积小、加载快，白块时间短），大图原图可以继续用渐进式 JPEG（保留渐进体验），或者接受 WebP 的"弹跳"换 50% 流量。没有完美格式，只有按场景的取舍。
做了这么多实测，最后给一张可以直接抄的选型表：
| 场景 | 推荐格式 | 理由 |
|---|---|---|
| 照片/缩略图/列表图 | WebP | q60~80 区间比 JPEG 省 40~50%，兼容 97.3% |
| 低质量海量图（瀑布流缩略） | AVIF | q40 极致小，省 59% |
| 图标/Logo/插画 | SVG | 矢量无限缩放，比位图小几十倍 |
| 截图（文字/UI） | WebP lossless | 无损 WebP 比 PNG 小 26%（MDN） |
| 详情页大图 | JPEG 渐进 或 WebP | 前者有渐进体验，后者省一半流量，二选一 |
| 透明背景 | WebP | JPEG 不支持透明，WebP 无损支持 |
| 动图 | WebP 动图 / AVIF 动图 | 比 GIF 小得多，还支持透明 |
用 <picture> 做回退，让老浏览器兜底 JPEG——兼容性交给标签，体积交给格式。
三个坑，都是我实际踩过的：
第一，别在浏览器端实时转格式。 我一开始图省事，用 Canvas 把用户上传的图在浏览器转 WebP——结果一张 8MB 的图转完要两秒，用户以为卡死了。后来改成 COS 预生成，用户上传完立刻能用，后端异步慢慢转。编码这种事，别让用户等。
第二，AVIF 的 q 值坑。 上线 AVIF 时我直接照搬了 WebP 的 q80，结果图比预期大一大截。查了才知道 AVIF 的 q 参数映射到不同的量化策略，必须按目标体积反推质量，或者用工具（如 Squoosh）可视化调。换格式 = 重新调参，不是改个后缀。
第三，别忘了那 6%。 全站切 WebP 后，有用户反馈图片裂了——一查，用的是老 Safari。<picture> 回退加上就再没出过事。格式再先进，也要给最后 6% 的用户留条路。
回到开头那个问题：你的图片该用什么格式？
如果让我用一句话总结：默认 WebP，海量低质图用 AVIF，图标用 SVG，大图看你要流量还是要渐进体验。JPEG 不是不能用，是"能用"和"划算"之间差着 40% 的流量——对图片站来说，这 40% 可能就是一半的带宽预算。
这些结论不是我拍脑袋，是这张 2000×1500 的照片在 Pillow 里跑了四组质量档、记了一堆毫秒数、外加 MDN 和 caniuse 的数据，才敢写出来。选格式这事，别信感觉，信数据。 你的站点跑一次同样的测试，五分钟就能知道该不该换。
最后补一句实在话：格式选型没有银弹。你的图片是照片多还是截图多、用户是老浏览器多还是新浏览器多、首屏要的是体积还是渐进体验——答案都不一样。数据 + 场景 + 回退方案，这三样凑齐了，格式怎么选都是对的。