把站内 4200 张图批量转格式能省多少？我们的实测：PNG 转 WebP 平均小 62%，JPEG 转 WebP 平均小 34%，WebP 再转 AVIF 还能再小 18%，但编码时间多五倍。这是去年 11 月一个设计工具站的项目，数据可以直接拿去估自己的站。
先算账再动手
这个站媒体库 4200 张图：PNG 1400 张，主要是界面截图和图标；JPEG 2800 张，博客配图和案例图。转之前总体积 3.1GB，转成 WebP 之后 1.4GB，平均压掉 55%。
PNG 那批收益最大，因为里面很多是界面截图，色块多、渐变少，WebP 对这类图特别友好。JPEG 那批收益小一些，因为原图本来就压过一轮。
AVIF 值不值
AVIF 压缩率确实更好。我们抽 200 张图对比，WebP 平均 96KB，AVIF 平均 79KB。但代价是编码慢：同一台机器转 WebP 用 12 分钟，转 AVIF 要 1 小时，CI 里根本跑不动。
我的判断是：首屏大图的 AVIF 值得，剩下 95% 的图用 WebP。为了 18% 的体积把构建时间拉长五倍，工程上不划算。
三个必踩的坑
第一个坑是质量参数直接照搬。WebP 的 q=75 和 AVIF 的 q=50 视觉质量接近，硬套同一个数不是太糊就是太大，得按格式分别调。
第二个坑是透明背景。PNG 转 WebP 支持透明，但有些老工具链会丢掉 alpha 通道，图标变黑底。转完必须抽一批 PNG 图标肉眼过一遍。
第三个坑是兼容兜底。AVIF 的浏览器支持已经不错，但旧设备还在用，用 <picture> 加 WebP 兜底，别只给一个 src。
什么图不该转
三类图建议保留原格式。图标类的小 PNG 和 SVG 本来就几 KB，转格式的收益还不如多一次请求；带大面积纯色文字的截图，WebP 有损模式会把字边缘压糊，我们用无损或者 q=90 才过关；GIF 动图别转 WebP 动图，转成 MP4 更小，实在不行就保留。
这个站转完第一版有 60 多张博客长图文字发虚，编辑在群里骂了一轮。后来用无损 WebP 重转那批，体积还是比 PNG 小 30%，问题解决。
落地方式
我们没手工转，改的是上传流程：编辑器上传时自动生成 WebP，原图留档。历史图片用脚本批量跑，跑完 grep 一遍 HTML 和数据库里的引用路径。这一步最花时间，因为总有几十张图是硬编码在正文里的。
这个站改完，移动端首屏图片传输从 1.9MB 降到 620KB。但要说清楚：格式只能解决体积，解决不了"该不该出现在首屏"。有些站首屏放三张装饰图，转成 AVIF 也救不回来。
转完之后要立个规矩
批量转换是一次性的，不立规矩三个月就反弹。我们给这个站加了两条：编辑器上传时超过 500KB 的图自动压缩并生成 WebP；每周跑一次巡检，把超过 300KB 的图列出来给内容团队。
巡检脚本不到 40 行，按页面路径输出图片体积排名，谁传了大图一目了然。这条规矩执行三个月，媒体库平均体积又降了 11%。
元析智能
为软件公司做 SEO 和 GEO 优化