WebP 无损相比 PNG 实际能为你节省什么

简短版本

对于相同的像素，WebP 无损通常比 PNG 更小。这就是人们使用它的实际原因。

但“通常”这个词很重要。WebP 无损并不是每个 PNG 的神奇替代品。它往往在带透明度的图片、截图、UI 截图以及图形/照片混合内容上节省最多。对于非常小的资源、经过高度优化的调色板 PNG，以及简单图标，它可能节省很少，甚至偶尔变得更大。

如果你在优化一个真实网站，正确的问题不是“WebP 是否比 PNG 更好？”而是：“我的哪些 PNG 转成 WebP 无损后能明显变小，同时不会带来兼容性或工作流问题？”

这是一个更窄的问题，也更容易回答。

这里的“无损”是什么意思

无损意味着解码后的像素与源像素完全一致。如果一个 PNG 被转换为 WebP 无损后再解码，图像像素应该是相同的。

这并不意味着文件本身相同。元数据、颜色配置文件处理、PNG 辅助块、伽马信息、时间戳以及工具特有的数据块，可能会根据你的转换流程被修改、剥离，或以不同方式表示。

如果你处理的是归档图片、印刷工作流、科学图像、法律证据，或任何文件容器承载重要非像素信息的场景，这一区分就很重要。对于普通 Web 分发，大多数团队主要关心视觉像素、透明度、尺寸和颜色一致性。

如果你发布用户提供的图片，元数据也是一个隐私问题。我们在如何在在线分享照片前移除 EXIF 元数据中讨论过这个更广泛的话题，但同样的原则也适用于这里：图片优化应当明确说明保留什么、移除什么。

为什么 PNG 压缩效果好，以及它的边界在哪里

PNG 是一种非常好的格式。它成为 Web 默认选择有充分理由：

• 它是无损的。
• 它支持 alpha 透明度。
• 它被广泛支持。
• 它可预测，且易于使用。
• 它非常适合扁平图形、截图、logo 和 UI 资源。

PNG 压缩通过对图像行进行过滤，然后应用 DEFLATE 压缩来工作。这个组合很有效，尤其是在相邻像素相似时。

问题不在于 PNG 不好。问题在于 PNG 很老。与较新的格式相比，它的压缩模型可用的技巧更少。即使用好的编码器优化过 PNG，你仍可能留下本可节省的字节，因为这种格式本身无法像 WebP 无损那样高效地表示某些模式。

这正是 WebP 无损发挥作用的地方。

WebP 无损有什么不同

WebP 无损使用的是专门为图像设计的压缩系统，而不是把通用压缩层附加到经过过滤的行上。在底层，它可以使用预测编码、颜色变换、调色板、向后引用和熵编码等技术，以紧凑方式表示重复或可预测的像素模式。

你不需要记住实现细节。一个有用的心智模型是：

PNG 擅长压缩行。WebP 无损有更多方式描述图像结构。

这种额外的灵活性，就是 WebP 无损经常能从同一源图像生成更小文件的原因。

Google 过去在自己的研究中曾描述，WebP 无损图片平均比 PNG 小约 26%。请把它视为方向性的基准，而不是承诺。你的图片并不是一个平均值。你的设计系统、截图、产品照片、插画、导出资源和 CMS 上传内容，都会有各自的表现。

WebP 无损通常在哪里节省最多

透明图片

PNG 常被使用，是因为它支持 alpha 透明度。WebP 无损也支持 alpha，并且通常能高效压缩它。

这对以下内容很有用：

• 产品抠图
• 贴纸和徽章
• 界面叠层
• 透明背景图表
• 导出尺寸过大的 logo

当 alpha 通道包含大块可预测区域、柔和边缘或重复形状时，节省会很明显。如果你有一个充满透明产品图片的目录，WebP 无损值得及早测试。

截图和 UI 截图

截图通常包含大面积纯色区域、重复界面组件、文本、图标、阴影，以及一些照片区域。这种混合内容对 PNG 来说可能比较尴尬，尤其是在尺寸很大时。

WebP 无损通常能很好地处理这些图片。一个作为优化后 PNG 为 900 KB 的整页 UI 截图，转换成无损 WebP 后可能变成 500–700 KB。有时节省更多。有时更少。但这个类别很有潜力。

如果这些截图出现在文档、营销页面、引导流程或案例研究中，累积效果会很实际。

插画和图像混合内容

许多现代 Web 图形既不是纯插画，也不是纯照片。想象一个 hero image，其中包含产品 UI、渐变、小图标、文字标签和嵌入照片。

PNG 可以完美保留它，但会生成很大的文件。WebP 有损或 AVIF 如果压得太狠，可能会在文字和边缘周围产生伪影。当精确边缘很重要时，WebP 无损可以是一个合理的折中方案。

如果你需要了解包括 AVIF 和 WebP 有损在内的更完整图片格式决策树，请参阅2026 年的图片格式：什么时候 AVIF 胜过 WebP，什么时候不会。

PNG 仍可能更好的地方

微小图标和简单资源

对于非常小的文件，格式开销很重要。一个 650 字节的 PNG 图标并不是明显的转换候选对象。WebP 可能节省 80 字节，也可能变得更大。

在这个尺度上，运维复杂性可能超过收益。如果文件已经很小、不阻塞渲染，并且缓存很久，你可能有更值得修复的问题。

精心优化的调色板 PNG

有些 PNG 比人们预期的小得多，因为它们使用了有限调色板。一个优秀的索引色 PNG 对于简单图形来说很难被超越。

这尤其适用于：

• 小 logo
• 像素艺术
• 扁平图标
• 简单图表
• 颜色很少的图形

在将 WebP 与粗糙的 PNG 导出文件比较时要小心。如果 PNG 是直接从设计工具导出的，带有不必要的元数据和较差的压缩设置，WebP 可能看起来好很多。但这并不意味着 WebP 能以同样幅度击败一个优化良好的 PNG。

公平的测试应当比较 WebP 无损和优化后的 PNG，而不是刚好被上传的那个文件。

本该使用有损格式的图片

这是一个不太显眼的错误：团队把 PNG 转成 WebP 无损，而这张图片一开始就不该是 PNG。

照片是最常见的情况。保存为 PNG 的全彩照片可能非常巨大。将它转换为 WebP 无损可能会减小文件，但通常仍会远大于高质量的 WebP 有损或 AVIF。

如果用户无法感知差异，无损往往是错误目标。产品摄影、编辑图片、背景和人像通常应使用合理质量设置的有损格式。

无损应保留给确切像素很重要的场景：UI 截图、图表、文本密集型图形、透明度、生成的图表，以及在有损压缩下会明显退化的资源。

除了字节，它还节省什么

最明显的节省是传输大小。更小的图片文件通常意味着更少带宽、更快下载，以及在慢速连接上更好的表现。

但还有一些次级收益：

• 访客在计量套餐上使用更少数据
• 图片缓存填充更快
• CDN 带宽降低
• 大规模场景下存储和备份体积减少
• 对性能预算的压力更小

这些节省并不是均匀分布的。一个 2 MB 的 PNG 转换为 900 KB 的 WebP，比五十个各减少 100 字节的图标更重要。

这就是为什么图片优化应按页面影响优先级排序，而不是按格式理念排序。如果 Lighthouse 标记了图片交付问题，请把它看作线索，而不是判决。我们的指南如何阅读 Lighthouse 报告而不惊慌解释了如何将有意义的性能问题与噪声诊断区分开来。

解码成本的权衡

文件更小并不是唯一的性能变量。浏览器还需要在绘制前解码图片。

PNG 解码成熟，通常很快。WebP 解码也被广泛支持且效率很高，但在某些情况下可能消耗更多 CPU。在现代设备上，这很少成为阻碍，但在低端手机、图片密集页面或首屏大型资源上，值得测量。

实用规则是：如果 WebP 无损能将一个大 PNG 减少 30–50%，网络节省通常占主导。如果它只把一个小 PNG 减少 3%，这种权衡大概不值得关注。

性能工作充满这类阈值决策。不要用同样强度优化每一个字节。

一个简单的测试方法

使用一组有代表性的样本，而不是单张图片。

创建一个文件夹，放入你实际网站中的示例：

• Logo 和图标
• 截图
• 产品抠图
• 图表
• CMS 上传的 PNG
• 社交预览图片
• 大型 hero 图形

然后比较三项：

1. 上传时的原始 PNG
2. 优化后的 PNG
3. WebP 无损版本

对于命令行工作流，团队常使用 oxipng、pngcrush、zopflipng 或 cwebp -lossless 等工具。具体工具不如“同类对比”的纪律重要。

跟踪：

• 文件大小
• 解码后的像素一致性
• 在目标浏览器中的视觉渲染
• 透明度正确性
• 颜色外观
• 构建时间
• CMS 或设计工作流摩擦

一个简单的电子表格就够了。加入原始文件大小、优化后 PNG 大小、WebP 无损大小、节省百分比，以及图片出现的页面。

然后按总节省字节排序。这个排序通常会告诉你该做什么。

交付：不要随意破坏旧客户端

WebP 现在在现代浏览器中的支持已经很广。对于大多数公共网站来说，使用它是安全的。不过，如果你的环境中包含嵌入式 webview、邮件客户端、旧版企业浏览器、原生应用或不常见的爬虫，请在直接替换 PNG 前进行测试。

保守模式是保留 PNG 作为 fallback，并在支持时提供 WebP：

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

这种做法很无聊，而无聊是好事。支持 WebP 的用户获得更小的文件。其他所有人获得 PNG。

如果你的构建系统会为资源生成指纹，并且 CDN 正确缓存它们，这并不难维护。如果你的 CMS 让替代格式变得麻烦，请从最大、重复最多的图片开始，而不是试图在一个 sprint 内转换整个媒体库。

隐私和本地处理

图片转换通常发生在构建管线或服务端媒体服务中。对许多团队来说这没问题。但如果你处理的是敏感截图、客户上传内容或内部文档，就要注意文件在哪里被处理。

浏览器端图片工具已经足够好，可以完成许多简单转换、预览和元数据检查。它有局限，但本地处理可以减少不必要的私有图片上传。我们在为什么在浏览器中处理图片是一种隐私收益中讨论过这些权衡。

对于内部资源，重点是政策清晰。要知道图片是否离开设备、转换后的版本存储在哪里，以及元数据是否被保留。

实用经验法则

当以下三点都成立时，使用 WebP 无损：

• 源文件当前是 PNG。
• 精确像素或干净透明度很重要。
• 与优化后的 PNG 比较后，WebP 无损能节省有意义的大小。

在以下情况下保留 PNG：

• 文件很小。
• PNG 已经经过调色板优化且有竞争力。
• 兼容性约束不寻常。
• 运维复杂性不值得所节省的字节。

在以下情况下使用 WebP 有损或 AVIF：

• 图片是照片类。
• 精确像素不重要。
• 质量设置可以在无可见损伤的情况下显著减小体积。

最佳图片策略很少是到处使用一种格式。它是一小组被一致应用的规则。

<!-- tool-cta:start -->

💡 试试这个： 将同一个 PNG 通过 Image Converter 处理，生成无损 WebP 版本，并直接比较文件大小。

<!-- tool-cta:end -->

那么，WebP 无损实际节省了什么？

它在 PNG 已经用尽压缩技巧的地方节省字节。有时这意味着适度的 10%。有时这意味着把一张大型透明图片几乎减半。放到真实网站上，节省通常集中在少数资源中。

这才是重点。WebP 无损不是相对于 PNG 的道德升级。它是针对特定工作的实用选项：在具备透明度和广泛现代浏览器支持的前提下，提供更小的无损 Web 图片。

在数据证明合理的地方使用它。在数据不支持的地方，让 PNG 保持原样。