打开一个网页，一半时间在等图片加载
先看关键判断
如果你正在处理CDN WebP，先别急着照搬网上的参数。你可能有过这样的体验：同一个页面，在手机上滑几下就能看到完整内容，换成某个老旧设备或弱网环境，却要盯着loading转圈十几秒。罪魁祸首往往不是HTML或CSS，而是那些动辄几百KB的图片。一张1920×1080的PNG截图可能超过2MB，即使压缩成JPEG，在高清场景下也常常突破500KB。当页面里有十几张这样的图片时，浏览器的网络请求就会排成长队。
过去几年，前端和运维团队想了很多办法：图片懒加载、CSS Sprite、使用CDN加速……但这些手段都绕不开一个核心问题——图片本身的体积。除非你愿意牺牲肉眼可见的画质，否则JPEG或者PNG的压缩率总有天花板。于是两个新格式出现了：WebP（由Google推出）和AVIF（由开放媒体联盟推出）。它们能在同等画质下把体积再砍掉30%~50%。
但是，新格式有一个尴尬的地方：不是所有浏览器都认识。如果你直接把所有图片改成WebP格式，那么仍在用旧版Safari或某些国产浏览器的用户就会看到一张空白框。这时就需要一种机制——根据来访浏览器的能力，自动返回它能打开的格式。这就是图片格式自动协商要做的事。
进阶阅读：此处可内链到“CDN WebP性能优化”指南。
自动协商：浏览器告诉服务器“我能吃什么”
配置前的检查
当我们访问一个网站时，浏览器发起的HTTP请求里会包含一个叫 Accept 的请求头。这个请求头就像点餐时告诉服务员：我能接受什么样的菜。对于图片来说，它可能长成这样：
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8这段文字的意思是：我最想要AVIF，如果没有就给我WebP，再不行就APNG、SVG或者普通图片格式。服务器（或CDN边缘节点）收到这个请求头后，就能判断出该浏览器支持哪些图片格式。如果服务器上恰好有同一张图片的WebP和AVIF两个版本，它就能挑选一个返回。
这个过程完全由HTTP协议驱动，不需要在页面上写任何JavaScript判断代码。不需要判断User-Agent，不需要维护一份浏览器兼容性名单。只要CDN节点能读取Accept头部并做出响应，一切就自动发生。用户侧的浏览器甚至不知道自己拿到的是另一种格式——它只管解码显示。
延伸阅读：此处可内链到“CDN WebP配置案例”相关文章。
CDN边缘节点：在离用户最近的地方完成格式转换
我的处理经验
理解了协商机制，接下来就是谁来执行协商。如果你把原始图片放在自己的源服务器上，让后端程序（比如Nginx或应用代码）根据Accept请求头动态生成WebP或AVIF，那么每一次新的请求都要占用CPU做转换运算，高峰期可能导致服务器负载飙升。更麻烦的是，你还要自己缓存转换后的版本，否则每次访问同一张图都要重新压缩一遍。
借助CDN边缘节点，这个问题解决得干净利落。CDN节点本身就是一个分布在全球的缓存层。你可以做这样的配置：
- 把原始图片（比如JPEG或PNG）上传到源站正常访问；
- 在CDN控制台开启“图片预处理”或“自适应图片”功能；
- 节点收到用户请求后，检查Accept头部；若支持AVIF，节点自行将原始图片转码为AVIF返回，并缓存该版本；若只支持WebP，则转成WebP；若都不支持，就返回原始JPEG/PNG。
在这个过程中，源站始终只需要保存一份原始文件。CDN边缘节点根据不同的浏览需求“按需加工”。加工后的文件缓存在节点上，下一次相同能力的浏览器请求同一张图时，直接命中缓存，连转码这一步都省了。
两种新格式：WebP与AVIF对比
实际操作要点
在决定开启哪种格式之前，有必要了解它们各自的特性：
WebP 由Google在2010年发布，支持有损和无损压缩，也支持透明通道（类似PNG）和动图（类似GIF）。目前主流的Chrome、Edge、Firefox、Opera以及Android系统浏览器都已经支持。Safari从14版本开始支持WebP。兼容性已经非常理想。
AVIF 基于AV1视频编码技术，2019年才标准化。它的压缩效率比WebP更高——在同画质下，文件体积可以再缩小20%左右。它同样支持透明通道、HDR和宽色域。缺点是编码计算量更大（首次转码会更慢），而且兼容性稍窄：Safari 16及以上、Chrome 85+、Firefox 93+才支持。目前桌面端旧版Safari（如macOS Catalina上的Safari 14~15）不支持AVIF。
所以推荐的策略是：AVIF优先，WebP兜底，原始格式做保底。CDN节点的配置应该让AVIF的权重最高，其次是WebP，最后才是原始JPEG/PNG。这样对支持AVIF的用户（主要是较新的设备）可以获得最优的体积缩减；对只支持WebP的用户也能享受到比JPEG更好的压缩率；而完全不支持这两种格式的极少数老浏览器，也能看到原始图片，只是加载慢一点而已。
想继续深入：此处可内链到“CDN WebP优化清单”文章。
补充参考：此处可内链到“CDN WebP故障排查实例”。
CDN WebP：压缩质量：别为了大小牺牲观感
配置前的检查
很多人在开启自动格式转换后，发现图片确实变小了，但仔细看有块状瑕疵或颜色失真。这是因为转码时使用的质量参数设置得太低。质量参数（通常是0~100的数值）决定了压缩的激进程度。
对于JPEG转WebP/AVIF，建议将质量设置在 75~85 之间。以一张原本500KB的JPEG照片为例，采用质量80的WebP压缩后，体积通常能降到200~250KB，肉眼几乎看不出差异。如果用同样的质量转成AVIF，可以进一步降到150~180KB。但如果把质量降到50，体积确实还能再砍一半，但画质就可能出现明显噪点和边缘锯齿。
更重要的是，不要对所有类型图片使用同一套压缩参数。对于截图、UI元素这类含有大面积纯色和锐利边缘的图片，有损压缩很容易产生伪影。此时可以设定“遇到PNG格式的原图，使用无损压缩模式”，让CDN节点转为无损WebP或无损AVIF。这样体积比PNG小30%~50%，但不会造成任何画质损失。
适配工作：后端和前端需要做哪些调整
配置前的检查
很多初次接触的人会担心：开启自动协商后，我页面上的img标签要改吗？答案是：完全不需要改。
因为协商发生在HTTP层面，浏览器用Accept头告诉CDN它要哪种格式，CDN返回相应的二进制流。浏览器收到后，根据Content-Type（比如image/webp）来解析。这个过程对标签的src属性和CSS的background-image属性都是透明的。你甚至在开发者工具的“网络”面板里看到请求的URL还是原来那张jpg，但实际返回的是webp。CDN节点在响应里加了Content-Type: image/webp 和 Vary: Accept 头，浏览器就会正确处理。
不过，有一点容易被忽略：Vary头部。当CDN根据Accept头部缓存不同格式时，它必须告诉下游缓存（包括浏览器本地缓存和中间代理缓存）：这个响应依赖于Accept请求头的值。如果缺少Vary: Accept，一个曾经请求过并缓存了WebP版本的节点，可能会错误地将WebP版本返回给一个不支持WebP的浏览器，造成破图。大多数专业CDN平台在开启自适应图片功能时会自动添加Vary: Accept，但如果你使用自建CDN（比如自编译的Nginx + njs或Lua），务必手动检查这一点。
风险意识与兜底机制
配置前的检查
虽然自动协商很强大，但并非没有风险。最常见的问题是：
- 源站没配置好导致转码失败。 如果连续几张图片转换后反而变得更大（因为CDN默认的压缩参数不合理），或者因为libwebp/rav1e库版本过低导致转码错误，用户看到的就是破损图片。建议先在少量图片或特定路径上测试，观察一周的日志和用户反馈。
- 回源流量增加。 首次请求某张图时，CDN节点需要从源站拉取原始文件，然后在节点上执行转码。这段时间会占用节点CPU。如果突然涌入大量从未请求过的新图片（比如新上架的商品图库），节点转码队列可能堆积，导致响应延迟增加。提前预估业务高峰，设置合理的转码并发限制或预热策略。
- 缓存驱逐策略。 转码后的WebP/AVIF版本占用的缓存空间比原始JPEG更大吗？不一定，因为文件变小了，但要注意节点同时需要缓存原始文件和多种转换版本。如果节点缓存空间有限，可能频繁淘汰旧文件，导致重复转码。建议为图片类资源设置更长的缓存时间（比如30天），并配合CDN的智能缓存策略。
如果你的业务场景高度依赖图片呈现（如电商、设计社区、图库网站），可以考虑以下验证与回滚方案：
- 先用A/B测试，让10%的流量走自适应图片，其余90%走原格式。通过对比平均页面加载时间、图片下载体积、以及用户的错误率来判断效果。
- 在CDN控制台保留一键关闭“图片自适应”或“WebP/AVIF转换”的开关。一旦发现兼容性问题，立刻关闭，恢复原状，再排查原因。
- 监控源站回源带宽和节点转码CPU使用率。如果回源带宽骤降（说明缓存命中率提高）但节点CPU飙升，需要确认节点实例规格是否足够。
相关阅读：此处可内链到“CDN WebP常见问题”专题。
实践建议：从哪一步开始
先看关键判断
如果你运营着一个中小型网站，想给用户提供更快的图片加载体验，但又不想搞得太复杂，可以按照以下顺序推进：
- 第一步：确认CDN平台能力。 先查阅你使用的CDN服务商文档，看是否支持“自适应WebP/AVIF”或“图片实时处理”。大部分主流CDN（包括Cloudflare、Akamai、阿里云CDN、腾讯云CDN等）都已经具备此功能。如果是在自建的Nginx/CDN上实现，需要借助ngx_http_image_filter_module或第三方模块（如libvips）配合Lua/JS脚本。
- 第二步：测试小范围资源。 选定一个目录（比如/static/images/）开启转换，观察三天内的日志，确认没有收到用户关于“图片无法显示”的反馈。同时检查各主流浏览器（Chrome、Edge、Safari、Firefox）的加载情况。
- 第三步：逐步扩大范围并监控性能。 当小范围稳定后，再扩展到全站静态图片。注意统计图片请求的平均大小变化。通常可以见到30%~50%的带宽节省。这个数据可以在CDN统计报表中提取。
- 第四步：调优质量参数。 根据业务类型调整压缩质量。对于人物摄影类，质量可以设置高一些（85~90）；对于图标和截图，使用无损模式或高质量有损（90~95）。
CDN WebP：总结
验证与回滚
图片格式自动协商不是一项新技术，但它仍然是免费且高效的性能优化手段。你不需要重写后端代码，不需要额外维护多套图片副本，只需要在CDN边缘节点做一次配置，就能让每一位访问者自动获得最适合他们浏览器的图片格式。WebP和AVIF的压缩潜力已经被大量实践证实，而自动协商机制通过HTTP协议的Accept头部完美解决了兼容性问题。
关键是要理解这背后的原理：浏览器声明能力，CDN按需转码并缓存，源站只需保持一份原始文件。当你掌握了这套逻辑，再去调整质量、管理缓存、制定回滚策略，就会有条不紊。希望这篇文章能帮你迈出图片优化的第一步。后续只要定期检查关键指标，CDN WebP就不会变成维护负担。
延伸阅读