图片往往是网页里最占体积的东西。一张从相机或者设计稿直接导出的图，动辄几百KB到几MB，而一篇文章的全部文字加起来可能还不到它的一半。站点越靠图片吃饭，这个矛盾越突出：首屏打开慢、带宽账单高、移动网络下的用户等得心焦。很多人第一反应是压质量，但把画质压到肉眼可见，是拿体验换体积。而且这条路是有天花板的，压到一定程度再往下走，图片就开始出现块状和涂抹，用户一眼就能看出来，等于拿观感换指标。
换格式是另一条路，而且常常不用在画质上让步。WebP就是这条路上比较成熟的一个选择，它同时支持有损压缩、无损压缩、透明通道和动画，等于把JPEG、PNG、GIF各自的活都接了过来。一个格式覆盖这三种用途，意味着你的图片处理流程可以只维护一条，不用按用途分叉，维护成本下降得比体积更明显。
省多少体积是有官方数字的。按Google的WebP文档，在同等画质下，有损WebP比JPEG小25%到34%；无损WebP比PNG小约26%。这两个区间不是绝对承诺，压缩率高度依赖图片内容：噪声多的照片提升有限，干净的插画和截图提升明显。所以别拿一个样本外推全站，最好挑几张有代表性的图实测一遍再下结论。实测的方法也简单：把同一张原图分别导出成两种格式，把质量调到肉眼难分高下，然后比文件大小，多试几张不同内容的图，你就能得到一个属于自己的参考值。
支持情况也得说清楚，这是换不换的前提。按官方给出的浏览器清单，有损WebP从Chrome 17、Firefox 65、Edge 18起支持，带透明和动画的完整支持则要Firefox 65、Safari 14以上；综合各家的统计，如今全球浏览器支持率大约在96%左右。剩下那几个百分点，主要落在老版本Safari、旧版IE和一些老旧设备上。判断标准是你自己的访客构成：如果后台显示还有可观比例的旧系统，就必须留回退；如果访客集中在近几年的设备上，直接用WebP是可以接受的。
兼容旧客户端有两种常规做法。一种是服务器端内容协商，看图浏览器在请求头里声明的接受格式，能收WebP就发WebP，否则发原格式；另一种是在页面里用picture元素，按优先级列出多个候选，让浏览器自己挑第一个能显示的。前者的好处是页面代码不用动，后者的好处是不依赖服务器配置。很多CDN和图片服务已经把这件事做成开关，打开即用，这对没有开发资源的站长最省事。如果不方便改服务器配置，也不想动页面代码，还有更简单的一种做法：让图片服务在返回时就按请求自动转换，把这个判断彻底交出去。
什么时候不该换，也要心里有数。WebP只支持8位色深，高色深、需要广色域的摄影素材不适合它；编码过程比JPEG慢，对按需实时转码的场景不友好；有损WebP在处理大面积平滑渐变加半透明时可能出现色带，这类图更适合用无损。还有一条容易被忽略：邮件客户端对WebP支持很差，桌面版Outlook不渲染，部分邮箱会把附件转成JPEG——所以站内图片可以换，发给订阅用户的邮件配图别换。
还有个新手常踩的坑：把已经是有损格式的图再无损编码一遍。这么做的结果往往不是变小，而是变大，因为你把原来的压缩痕迹当作细节完整保留了下来。正确的做法是从源头处理——保留原始的PNG或高质量素材，再统一导出成目标格式和目标尺寸，而不是在成品图上来回转换。这条规律和音视频转码是一个道理：每一次有损压缩都会留下痕迹，后续的处理只会把这些痕迹一并固化，越转越差，源头才是最省事的地方。
尺寸往往比格式更值得先动手。一张4000像素宽的图放进只有800像素宽的版位，即使换成WebP也还是浪费。把图片按实际展示尺寸裁好，再选格式，收益通常比只换格式更大。这一步不需要任何技术判断，却常常被跳过，因为“换格式”听起来更像一次正经的优化。先缩尺寸再换格式，两步都做完你会发现，真正省下来的体积大头往往来自第一步，而它几乎不需要任何技术判断。
落地的顺序可以很简单：先统计站上最大的那批图片，把它们缩到实际需要的尺寸，再转成WebP，然后在页面上加回退。改完之后用性能工具复查一遍，重点看首屏最大内容的加载时间有没有降下来。别一次全站替换，先挑流量最高的几个页面做，确认没问题再铺开，出问题时影响面也小。上线之后留意一段时间的数据，重点看跳出率和首屏速度有没有变化，如果用户停留时间反而变短，那说明压缩过头了，把质量调回来一点再试。
图片格式不是越新越好，而是合不合适。WebP的好处在于它在体积、功能和支持度之间拿到了一个比较稳的平衡，代价是一部分老客户端需要回退、一部分高色深素材不合适。把它用在合适的地方，你几乎不用牺牲画质，就能把加载速度和带宽一起降下来，这是少数能同时让用户和账单都满意的优化。前提是每一步都做对了，而不是盲目地把所有图片一次性换掉。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
