我为什么总把 PNG 转成 WebP（以及唯一的例外）

我桌面上有个文件夹，名字就叫 to-shrink。有好几年，它都是截图们的坟场——各种 2 MB 的仪表盘 PNG、做了一半的原型稿，我随手就发给那些其实根本不需要看我 2 MB 屏幕的人。直到某天下午，我真把这个文件夹打开，认真算了一笔账：它居然比我那一周上线的整个应用还大。PNG 让人不易察觉的地方就在这儿。它是个很棒的格式，却在悄无声息地浪费掉惊人的空间，而我们大多数人从来不会留意——毕竟带宽便宜，文件也"能正常打开"。

所以，我想把这个道理讲清楚，就是当年我多希望有人早点跟我说的那番话：如果一张 PNG 是要放到网站上的——是拿去给人"看"的，而不是拿去"改"的——那它几乎肯定该换成 WebP。

PNG 真正的强项在哪

PNG 是无损的。你放进去的每一个像素，都会原封不动、分毫不差地出来。对一个源文件来说，这是实打实的优点。正因如此，你的设计软件才会导出 PNG，截图才是 PNG，凡是带着锐利边缘和透明通道的东西都爱用它。无损意味着你可以打开、微调、再保存，来回折腾一百遍也不损失任何东西。

问题在于，"完美保留每一个像素"这个承诺，是要拿字节来买单的。把一张照片存成 PNG，它会忠实地记下渐变、传感器噪点，以及那些哪怕只是近似处理、你的眼睛也永远察觉不到的细微色差。你花的是全价，买回来的却是没人看得见的细节。

WebP 能做，而 PNG 做不到的事

WebP 是 Google 对一个朴素问题的回答：要是我们干脆做个更好的格式呢？它能做两件 PNG 做不到的事。一是想要的时候可以做"有损"压缩——像 JPEG 那样丢掉人眼感知不到的部分，只是手法更聪明；二是它在这么做的同时，还能保留完整的 alpha 透明通道。第二点才是那个不动声色的奇迹。过去很多年，摆在人们面前的一直是"要透明，还是要小文件，二选一"。WebP 两样都给你。

实际操作中，把一张照片类、或截图偏多的 PNG 以合理画质转出来，体积通常会小上 60% 到 90%。不是 10%，是 60% 到 90%。一张 1.8 MB 的截图能变成大约 250 KB，两张并排一放，你根本分不出谁是谁。这个测试我在自己身上做过的次数，多到有点不好意思承认，每回都笃定这次一定能揪出 WebP 的破绽。可我从来没成功过。

让我彻底信服的那组对比

下面是上个月我批量转换时随手记下的大概数字：

看那个 logo。它几乎没怎么动——而这条不起眼的脚注，恰恰是关键。

什么时候我懒得转

简单的图形——纯色块、就那么几种颜色、边缘干脆利落——正是当年 PNG 被设计出来要压缩的东西，它干这活儿的水平跟谁比都不差。一个双色图标、一张线条示意图、一个 QR 码：让它们保持 PNG 就好；要是手头有矢量文件，那就更该直接发 SVG。WebP 处理这类文件不会有什么坏处，但也帮不上什么实质的忙，你反倒白白多添了一道工序。

另一种我不转的情况，是源文件。任何东西只剩"唯一一份"的时候，我绝不去动它。WebP 的有损模式是一扇单向门：丢掉的细节，就再也回不来了。所以，这就是我从不破例的那条规矩——发布的是副本，编辑的原件留在原地。在我电脑上，这实实在在就是两个文件：PNG 待在项目文件夹里，WebP 发到网站上。花不了几个成本的保险，而我一次都没后悔过。

"可它真能到处都正常显示吗？"

这曾经是个像样的质疑，但如今真的站不住脚了。凡是大家实际会用的浏览器，从 2020 年前后就都支持 WebP 了——Chrome、Safari、Firefox、Edge，一个不落。邮件客户端确实还参差不齐，一些老掉牙的企业软件对它的态度也古怪，所以要发邮件通讯，我还是会回头选 JPEG。但要说开放的网络？直接上 WebP、连后备方案都不留，早在好些年前就不再是什么冒险之举了。

换作我，会怎么做

说句实话，我在这个站上做那个 PNG 转 WebP 的转换器，纯粹是因为受够了把截图拖进网上七七八八的工具去压缩，事后还总不太确定我的文件到底流落到哪儿去了。所以我更愿意推荐的，是那个乏味又私密的版本：就在你自己的机器上、在浏览器里转换，文件从头到尾不离开你的设备。把 PNG 拖进去，看着体积那一栏往下掉，再把 WebP 下回来。

不过工具其实是次要的。重点是把习惯养起来。一旦"编辑用 PNG，发布用 WebP"变成本能，你就不会再把 2 MB 的截图甩给别人，你的页面白白就变快了，桌面上那个 to-shrink 文件夹也终于能一直空着。我那个，已经空了差不多一年。小小的胜利——我乐意收下。