图像压缩完全指南：JPG、PNG、WebP 按用途选择

2026-04-13发布 8分钟阅读

摘要 (TL;DR)

上周末我把一张猫咪照片丢进 Squoosh，原图 4.2MB 的 JPG 用质量 80 重新输出后变成 380KB，缩小了 91%。在手机屏幕上，我说实话分不出和原图的区别。这就是有损压缩正常工作时该有的样子。每次我忘记这一点，就会打开某个博客等 3 秒看一张 2MB 的 hero 图通过 LTE 加载完成，于是教训自己回来了。

图像格式的选择不是”哪个最好”，而是”用来做什么”。像照片这种连续色调多的图像适合有损压缩系列：JPEG、WebP（有损）、AVIF。在相同视觉质量下，WebP 通常比 JPEG 小 25–35%，AVIF 比 JPEG 小 40–50% 左右。反过来，logo、图标、截图这类边缘清晰、文字可读性重要的图像则用 PNG、WebP（无损）、TIFF 这类无损格式更安全。如果同时要透明度和动画，候选是 WebP、APNG、AVIF。浏览器支持方面，截至 2026 年初，WebP 自 Chrome 32（2014）、Firefox 65、Safari 14（2020 末）以来事实上已是全平台支持；AVIF 在 Chrome 85（2020 年 8 月）、Firefox 93（2021 年 10 月）、Safari 16（2022 年 9 月）之后能正常显示。一个合理的基线是”矢量 logo 用 SVG，照片用 WebP 或 AVIF，截图用 PNG”，需要兼容老环境时，用 <picture> 元素提供 JPEG 回退。

背景与概念

JPEG、WebP（有损）、AVIF 等有损压缩通过丢弃人眼不太敏感的信息来缩减文件体积。核心步骤有两个。第一是量化（quantization），把频域系数按整数近似，对高频成分裁剪得更粗。在照片这种灰度变化平缓的图像里几乎看不出来，但在锐利边缘附近可能会出现”块边界”。第二是色度二次采样（chroma subsampling），把色差通道（Cb、Cr）的分辨率降到亮度（Y）以下。4:4:4 保留全色度，4:2:0 在水平和垂直方向都减半。大多数默认值是 4:2:0，所以含红色、蓝色文字的图像边缘容易出现晕染。

JPEG 是基于离散余弦变换（DCT, Discrete Cosine Transform）的格式，1992 年标准化。WebP 借用了 VP8 视频编码器的帧内编码技术，AVIF 则借用了 AV1 的帧内工具集，所以两者在预测、变换、量化方面比 JPEG 现代得多——更大的块尺寸、方向预测、更强的熵编码。PNG 完全是另一类，使用 LZ77 系列的 deflate 算法做无损压缩，并通过 alpha 通道支持透明度。所以 PNG 不会损失质量，但在连续色调多的照片上文件会非常大。

另一个相关概念是渐进式解码。Progressive JPEG 和隔行 PNG 让用户先看到低分辨率版本，再随着字节到达逐步细化。WebP 和 AVIF 现在通常是单遍解码，对超大图像或慢速连接才比较关键。SVG 不是压缩位图而是矢量描述，体积取决于形状数量和文本本身的压缩（gzip、brotli 对 SVG 源文件效果非常好）。

对比与数据

格式有损无损透明度动画照片平均压缩比2025 浏览器支持
JPEG是否否否约 10:1全部浏览器
PNG否是是APNG 扩展约 2–3:1全部浏览器
WebP是是是是比 JPEG 小约 25–35%Safari 14（2020）以后基本全平台
AVIF是是是是比 JPEG 小约 40–50%Chrome 85+、Firefox 93+、Safari 16+
GIF是（256 色调色板）否1 位是不适合照片全部浏览器

请把这些数字当作总体趋势。实际压缩比严重依赖内容、编码器、预设、目标质量。同一张图，JPEG 质量 85 和 60 的体积可以差 3–4 倍；AVIF 用快速预设时优势会缩到与 WebP 接近。Google 和 Mozilla 在 2019–2023 年发布的基准测试报告：在等同 SSIM 下 WebP 比 JPEG 节省约 26–34%，AVIF 节省约 40–50%——但前提是慢速预设和经过调优的质量目标，不是大多数编辑工具的一键默认值。

另一个维度是编码与解码成本。JPEG 在任何设备上解码都只要几分之一毫秒，WebP 接近。AVIF 解码 CPU 占用更高，高质量预设的编码可以达到每张数秒。这种代价对构建期资产管线没问题，但对每次上传都要服务端实时重编码的用户生成内容场景就比较尴尬。

实战场景

**场景 1 — 博客缩略图与 hero 图。**我自己博客的 hero 图原本是 1.8MB，重新用 WebP 质量 82 导出后变成 210KB，在 Lighthouse 的限速 4G 配置下 Largest Contentful Paint 从 2.4 秒降到 1.1 秒。默认输出 WebP，需要兼容老环境时用 <picture> 加 JPEG 回退。务必先把图像缩到实际 CSS 显示宽度再导出，否则把 3000 像素宽的图塞进 600 像素容器，无论格式如何都是浪费带宽。

**场景 2 — Logo 与图标。**有矢量原图就先用 SVG。我有一次在某营销页看到一个红色 logo 被导出成 JPEG 质量 75，每个字母周围都有粉色的光晕。色度二次采样在 4:2:0 下，红色边缘几乎是最先被毁掉的。如果只有位图，就用 PNG 或无损 WebP。把 logo 当成不能有损压缩的资产来对待，而不是一个可优化的对象。

**场景 3 — 截图与 UI 捕获。**截图默认 PNG。浏览器 chrome、代码片段、CJK 字体在 JPEG 里的伪影都很明显——我连续两次被文档评审者标记”等宽字体看起来糊”之后就一直坚持这条规则。要再缩文件，可以用 pngquant（macOS 上 brew install pngquant）把调色板压到 256 色，UI 截图通常完全看不出差别，文件常常能再小 4–6 倍。文档站可以把 PNG 和 CSS 响应式图片标记搭配使用，让 retina 屏拿到 2x 资产，老屏幕拿 1x，这通常比换格式省得更多。

**场景 4 — 源素材的归档。**对那些以后可能再加工的原图（摄影母片、原始扫描、产品图），冷存储里保留无损副本（TIFF 或无损 WebP），按需派生有损交付版本。反复重压一张有损 JPEG 每轮都会再损失质量（“代际损失”），所以你需要一份干净的源头随时回到。

常见误解

**“PNG 永远是最高质量。“**作为无损格式它确实能完美还原，但对照片来说这种纯净意味着比必要大几倍的文件。在移动端，几 MB 的照片会拖累感知加载时间和 Core Web Vitals。

**“WebP 在所有浏览器都不能用。“**自 2020 年末 Safari 14 起，所有主流浏览器都支持。如果真有遗留环境要兼容，用 <picture> 加 JPEG 回退是个干净的解决方案。

**“AVIF 是魔法。“**压缩效率确实出色，但编码比 JPEG 或 WebP 慢得多。在我的 M2 MacBook Air 上，avifenc --speed 4 一张 2400×1600 照片要 5–9 秒；用 --speed 0 可以到 30 秒以上。老款移动设备的解码也可能成为问题。AVIF 比较适合批量管线和构建期优化，不太适合在主路径上对每个用户上传都重新编码。

**“用 JPEG 就行。“**这在 2015 年前后还合理，但现在 WebP 和 AVIF 在相近质量下几乎都能做到更小，而且支持已经普及或接近普及。新管线应该把 WebP 当作基线而不是 JPEG。

**“质量设置越高越值得。“**对 JPEG 或 WebP，质量超过 85 之后文件体积增长得比感知质量快得多。观众很难分辨质量 85 和 95，但文件可能大一倍。用感知指标（SSIM、butteraugli）来评估，而不是把质量滑块当作线性刻度。

“压得好就不用 resize。“图像交付里最大的单点收益往往来自按合适尺寸发送而不是压缩参数调优。一张 800 像素宽的 WebP 几乎总比 3000 像素宽的 WebP 轻，无论质量设置如何，因为你是在去掉像素，而不是近似它们。

决策清单

  1. 源是矢量吗？是 → 存为 SVG。
  2. 需要透明度吗？
    • 是 + 照片型 → WebP（有损 + alpha） 或 AVIF。
    • 是 + logo / 图标 → PNG 或 无损 WebP。
  3. 需要动画吗？→ WebP 动画、APNG、AVIF。GIF 因为 256 色限制不适合照片。
  4. 内容是照片或渐变密集型？→ 默认 WebP（有损），带宽敏感时再加 AVIF。
  5. 内容是截图或文字密集型？→ 优先 PNG 或 无损 WebP。
  6. 需要最大兼容性？→ 用 <picture> 元素，按 AVIF → WebP → JPEG 顺序提供回退。

相关工具

想直接试一下本文讨论的取舍，可以用 relatedToolUrl 里的 Patrache Studio 图像压缩工具，按有损/无损选项变换 JPEG、PNG、WebP。图像通常和文档、链接一起出现，所以建议同步阅读 浏览器 PDF 合并/拆分的安全收益 和 二维码安全：动态码风险与短链陷阱，这样在做含图、含文档、含链接的资料时能保持一致的判断标准。

参考资料

相关工具

tools.patrache.studio/image/compress/