WebP、AVIF、PNG 怎么选：网页图片格式实战指南

图片格式讨论经常变成一句口号：“全部用 WebP”或者“全部用 AVIF”。实际选择取决于图片内容、显示尺寸和需要支持的浏览器。

这篇文章给出判断流程、回退写法和容易踩的坑。

快速结论

表格只是起点。最终应该测量实际文件大小和显示效果。

浏览器支持决定的是下限，不是上限。WebP 从 Chrome 32（2014）、Firefox 65（2019）和 Safari 14（2020）开始支持。AVIF 更晚：Chrome 85（2020）、Firefox 93（2021）、Safari 16.1（2022）。picture 同时提供两种格式，现代浏览器不需要 JavaScript 就能选到更好的那个，但内嵌 webview、企业旧浏览器和渲染能力有限的邮件客户端仍然需要回退。不要凭感觉假设，先看站点分析数据；哪怕只有 2% 的 Safari 15 流量，那也是一批会看到 JPEG 的用户。

决策顺序应该是：先看内容类型，再看是否需要透明，然后看显示尺寸，最后才看浏览器下限。很多团队反过来，因为 AVIF 最新就先用 AVIF，结果发现一张 4000 像素、带文字的截图，效果还不如原来的 PNG。

各格式的适用场景

PNG

PNG 是无损格式，每个像素都保留，适合截图、图表、文字和边缘锐利的图片。代价是体积：照片类 PNG 往往比 JPEG 或 WebP 大好几倍。

适合：

• 需要精确像素值。
• 图片包含文字或线条。
• 需要广泛兼容。
• 作为后续编辑的源文件。

PNG 也不是单一编码，而是一组选项。颜色很少的截图可以存成 256 色调色板 PNG（常叫 PNG-8），体积往往只有 24 位 PNG 的一小部分；渐变和照片在这种模式下会出现明显色带，所以要用实际图片测试，而不是所有图都套同一个预设。PNG 支持 8 位和 16 位通道、alpha 通道，还支持 APNG 动画。浏览器能显示 APNG，但不少转换流程会悄悄丢掉动画块，只留下第一帧。如果转换后动图变成了静止图，多半就是这个原因。

JPEG

JPEG 是有损格式，兼容性极好。照片仍然可以使用，但现代格式通常能在相似质量下做到更小。JPEG 不支持透明。

有两个 JPEG 专属的坑值得记住。印刷软件导出的 CMYK JPEG 在浏览器里可能颜色反转或严重偏色，因为浏览器按 RGB 解释；同一张图在 Photoshop 里正常，在 Chrome 里却完全不对。另外，JPEG 的色度分量通常按 4:2:0 降采样，白底上的锐利红色文字压缩后会出现彩色毛边。渐进式 JPEG 能改善加载时的观感，但解决不了这两个问题。带彩色文字的截图，正确做法是用 PNG 或无损 WebP，而不是把 JPEG 质量调得更高。

WebP

WebP 支持有损、无损、透明和动画，当前主流浏览器都支持，是比较安全的现代默认值。有损 WebP 通常比同质量 JPEG 小 25% 到 35%；无损 WebP 对相同像素也常比 PNG 小。

适合：

• 想要现代格式且兼容性广。
• 需要透明或动画。
• 不想维护太复杂的回退链。

底层上，WebP 是三种相关格式：有损 VP8、无损 VP8L，以及用于 alpha 和动画的扩展容器 VP8X。编码器会自己选择，cwebp -q 80 生成有损 WebP，-lossless 生成 VP8L；同一张截图，两种输出的体积可能相差一个数量级以上。常被引用的“比 JPEG 小 25% 到 35%”说的是照片内容、同等质量下的有损 WebP，不是所有图片。小图标用无损 WebP 可能反而比优化过的 PNG 大；动图上，WebP 通常远小于 GIF，但比调好的 AVIF 大。

AVIF

AVIF 基于 AV1 图像格式，照片类内容经常能做出最小文件，尤其在低码率下。它支持透明和动画，但编码更慢，兼容性不如 WebP。

适合：

• 能提供 WebP 或 JPEG 回退。
• 构建流程能承受较慢的编码。
• 实测确实有体积或质量收益。

AVIF 的代价不只在编码：一张大图的编码时间可能是 WebP 的好几倍。解码也比 JPEG、WebP 更吃 CPU，在低端手机和交互密集的页面上要特别留意。它用 10 位色深，支持胶片颗粒合成，所以在渐变和暗部场景下，同等体积可能比 WebP 更干净；但质量参数调得太激进时，皮肤和文字会被抹平，而在高分辨率屏幕上很容易看不出来。按布局实际使用的尺寸编码，在 100% 比例下比较，源文件如果构建时能重新生成，就不要提交进仓库。

实用的回退写法

picture 元素让浏览器选择第一个支持的 source：

<picture>
  <source srcset="/images/hero.avif" type="image/avif" />
  <source srcset="/images/hero.webp" type="image/webp" />
  <img
    src="/images/hero.jpg"
    alt="仪表盘预览"
    width="1200"
    height="630"
    loading="lazy"
    decoding="async"
  />
</picture>

几个关键点：

• img 不能省，它提供回退和 alt 文本。
• width 和 height 预留空间，避免布局偏移。
• loading="lazy" 适合首屏以下的图片，首屏最大内容绘制图片不要懒加载。
• LCP 图片应使用 fetchpriority="high"。
• 大多数情况下浏览器只会下载一个 source。

type 属性是回退能安全工作的关键。带上它，浏览器会在下载前跳过不支持的格式；不带它，浏览器可能选中文件、开始解码、失败，然后直接显示坏图，而不是继续尝试下一个 source——HTML 规范并不要求解码失败后自动回退。如果用了带 w 描述符的 srcset，就必须同时写 sizes。没有 sizes 时，浏览器假设图片占满整个视口宽度，可能会给一张 320 像素的卡片下载 1600 像素的文件。症状是移动端布局明明很小，LCP 图片却大得离谱。

服务端内容协商是另一条路：CDN 读取 Accept: image/avif,image/webp,...，在同一个 URL 返回最合适的格式。标记更干净，但响应必须带 Vary: Accept，否则共享缓存可能把 AVIF 发给一个不会解码的客户端。调试也更难，因为 URL 不再能说明格式。静态站点用 picture 更可预测；已经正确处理这件事的图片 CDN，用内容协商可以省掉重复标记。

压缩和质量

格式转换和压缩是两件事。WebP 文件也可能很大，如果质量参数太高，或者尺寸远超实际显示尺寸。

合理流程：

1. 缩放到布局实际显示的最大尺寸。
2. 根据内容选择格式。
3. 在显示尺寸下选择看起来正确的质量档位。
4. 比较文件大小和视觉质量。
5. 把原始源文件放在部署目录之外。

截图和文字从无损 WebP 或 PNG 开始；照片从 AVIF 或 WebP 的适中质量开始比较。

图片压缩工具 可以在不上传服务器的情况下减小体积。格式转换可以用 PNG 转 WebP、JPG 转 WebP，需要兼容源文件时用 AVIF 转 PNG。

不同编码器的质量参数不能直接比较。WebP 的 -q 80 和 AVIF 的 -q 60 都用 0-100 的刻度，但两套数字并没有互相校准，同一个值在两个工具里可能产生肉眼可见的不同结果。下面只是起点，最终要在实际显示尺寸下看效果：

永远从原始图转换。把 JPEG 再压成 WebP 不会恢复细节，只会叠加第二次压缩，结果甚至可能比原 JPEG 更大。缩放同理：每个输出宽度都从全分辨率原图编码一次，而不是拿已经压过的文件反复缩放。

元数据、色彩配置和方向

转换工具可能会：

• 去掉 EXIF，包括方向信息。
• 转换或丢弃色彩配置。
• 改变 alpha 通道表示。
• 用不同方式重新编码动画帧。

如果方向或色彩准确度重要，必须验证输出。一张在某个查看器里正常的照片，可能因为色彩配置丢失而在另一个环境里偏色。

方向问题很具体。手机相机经常按横屏存储像素，再写一个 Rotate 90 CW 之类的 EXIF 方向标记；浏览器会按标记把图转正。转换器如果复制了像素却丢了标记，产出的就是一张躺倒的图，而且不会有任何报错。exiftool -Orientation photo.jpg 能看到原始标记，exiftool converted.webp 应该要么保留同样的标记，要么像素已经转正。不要假设库会自动处理。

色彩配置出问题更安静。在 Display P3 里编辑、保存时又没带 ICC 配置的照片，会被当成 sRGB 解释，饱和色会变灰；反过来则会过饱和、高光被裁掉。构建流程里要明确选择：用 sharp().withMetadata() 之类的选项保留元数据，或者显式转成 sRGB，然后用 exiftool -ColorSpace -ProfileDescription 验证。面向公众的上传还要用 exiftool -gps:all= 去掉 GPS 坐标，一张商品图可能暴露家庭住址。

与 Core Web Vitals 的关系

图片影响三个指标：

• LCP：首屏大图常常是最大内容绘制。使用尺寸合适的现代格式，不要懒加载，并设置 fetchpriority="high"。
• CLS：设置 width、height 或宽高比，避免布局跳动。
• INP：图片解码可能和交互竞争主线程。使用 decoding="async"，避免超大图片。

LCP 图片值得预加载，但只预加载一张。<link rel="preload" as="image" href="/images/hero.avif" type="image/avif" imagesrcset="..." imagesizes="..."> 能让下载在解析器到达 picture 之前开始；把所有候选格式都预加载就失去意义了，还会和关键 CSS 抢带宽。如果这张图就是 LCP 元素，不要加 loading="lazy"，也不要把它藏进预加载扫描器看不到的 CSS 背景图。用了 srcset 时，写错 sizes 比不写更糟：浏览器会相信它，下载一个过大的文件，LCP 指标如实记下这次浪费。

CLS 也有类似的陷阱。width 和 height 属性只有在 CSS 不用 width: 100%; height: auto 覆盖、且容器没有固定宽高比时，才能真正预留空间。优先用现代的 aspect-ratio，或者给图片套一个固定比例的容器，让预留的盒子在响应式布局变化后仍然有效。CLS 0.1 是“良好”和“需要改进”的分界线，一张没设尺寸的首屏大图就可能超标。

文件更小不一定更好。如果图片模糊，或者浏览器需要下载多个 source，实际体验仍然会变差。应该测量真实页面。

什么时候不要转换

不要转换：

• 已经很小且压缩良好的图片。
• 有损压缩会让文字发虚的 PNG 截图。
• 转换器无法保留复杂时序的动图。
• 必须保持字节一致的归档或法律文件。

还有两种情况容易漏掉。带签名或校验和的资源（例如在清单里用内容哈希引用的图片），签名之后不能再重新编码；签名验证的是字节，不是像素。已经经过图片 CDN 的图，也不要在应用构建里再转一次，因为 CDN 交付时还会再压一遍，第二次有损压缩没有任何收益。整条链路只让一个环节负责格式转换。

转换是工具，不是规则。最好的格式是在实际显示场景下满足质量要求、体积最小的那个。

决策清单

1. 图片内容是照片、截图、文字、图标还是动画？
2. 是否需要透明？
3. 最大显示尺寸是多少？
4. 必须支持哪些浏览器？
5. 构建流程能否生成多种格式？
6. 转换后在显示尺寸下是否清晰？
7. 是否设置了尺寸以避免布局偏移？

回答完这些问题，格式选择就清楚了。收到现代格式但需要兼容源文件时，可以用 WebP 转 PNG 转回可编辑格式。

上线前做一次短验证：

这套建议也有不适用的时候。品牌 Logo、需要像素级一致的法律存档，不管体积多大都应该用 PNG 或原始文件。很小的图标，SVG 或优化过的 PNG 通常比有损照片编码更合适。交付目标是邮件客户端或受管控的企业浏览器时，能依赖的仍然只有 JPEG 和 PNG。“照片用 AVIF”是开放 Web 上的默认值，不是放之四海皆准的规则。