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

> 按照片、截图、透明图、动图分别比较 WebP、AVIF、PNG 和 JPEG，给出兼容性回退方案、压缩流程和 Core Web Vitals 注意事项。

**快速答案:** 照片类图片优先用 AVIF 或 WebP，并提供回退；截图、文字和需要精确像素的图片用 PNG 或无损 WebP；兼容性优先时用 JPEG。通过 picture 元素提供多格式，并始终设置 width 和 height，避免布局偏移。

## 核心要点

- 格式选择取决于内容类型：照片、截图、透明图和动图的表现不同。
- AVIF 通常文件更小，但编码更慢，旧浏览器需要回退。
- WebP 兼容性好，是没有 AVIF 时的安全现代默认值。
- PNG 是无损格式，适合锐利 UI、文字和颜色较少的图片。
- picture 元素配合明确尺寸，可以兼顾兼容性和布局稳定性。

---

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

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

## 快速结论

| 内容 | 首选 | 回退 | 原因 |
| --- | --- | --- | --- |
| 照片和复杂图像 | AVIF | WebP、JPEG | 同等质量下通常最小 |
| UI 截图和文字 | PNG 或无损 WebP | PNG | 边缘锐利，像素精确 |
| 需要透明背景 | WebP 或 AVIF | PNG | 支持 alpha 且体积更小 |
| 图标和简单图形 | SVG | PNG | 矢量，分辨率无关 |
| 动图 | AVIF 或 WebP | GIF | 通常比 GIF 小，但要看兼容性 |
| 最大兼容性 | JPEG 或 PNG | 无 | 几乎所有环境都支持 |

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

浏览器支持决定的是下限，不是上限。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 的用户。

| 兼容下限 | 可以要求的格式 | 实际代价 |
| --- | --- | --- |
| 所有浏览器 | JPEG、PNG、GIF | 体积最大，但没有意外 |
| Safari 14+ / Chrome 32+ | WebP | 安全的现代默认值 |
| Safari 16.1+ / Chrome 85+ | AVIF + WebP 回退 | 照片最小，构建时间更长 |

决策顺序应该是：先看内容类型，再看是否需要透明，然后看显示尺寸，最后才看浏览器下限。很多团队反过来，因为 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：

```html
<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 的适中质量开始比较。

[图片压缩工具](/tools/image-compressor) 可以在不上传服务器的情况下减小体积。格式转换可以用 [PNG 转 WebP](/tools/png-to-webp)、[JPG 转 WebP](/tools/jpg-to-webp)，需要兼容源文件时用 [AVIF 转 PNG](/tools/avif-to-png)。

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

| 内容 | 起始参数 | 重点检查 |
| --- | --- | --- |
| 照片，AVIF | `avifenc -q 60`（质量 0-100） | 肤色、渐变、叠加文字 |
| 照片，WebP | `cwebp -q 80` | 边缘光晕、天空色带 |
| 截图，无损 WebP | `cwebp -lossless -z 9` | 文字清晰度与 PNG 体积对比 |
| 截图，调色板 PNG | `pngquant --quality=65-80` | 渐变和阴影的色带 |

永远从原始图转换。把 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](/tools/webp-to-png) 转回可编辑格式。

上线前做一次短验证：

| 检查项 | 失败信号 |
| --- | --- |
| 在不支持 AVIF 的浏览器里打开页面 | 坏图，或意外下载了很大的 JPEG |
| 在移动端视口看网络面板 | 首屏图下载了桌面宽度 |
| 在 100% 比例下比较转换结果 | 文字毛边、色带、皮肤被抹平 |
| 在 devtools 里检查 `width` / `height` 或 `aspect-ratio` | 图片加载时布局跳动 |
| 用 `exiftool` 检查输出 | 方向标记或 ICC 配置丢失 |

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

## 常见问题

### AVIF 一定比 WebP 小吗？

不一定。AVIF 在照片类内容和低码率下经常更有优势，但结果取决于图片、质量参数和编码器。应该在实际使用的质量档位下测量文件大小，而不是套用固定结论。

### WebP 支持透明背景吗？

支持。WebP 的 lossy 和 lossless 模式都支持 alpha 透明，AVIF 也支持。需要精确像素或广泛旧版兼容时，PNG 仍然有用。

### 为什么转换后图片变模糊了？

有损转换会丢失细节。截图、文字和线条图应该使用无损 WebP 或 PNG，而不是激进的有损压缩。比较时应该看实际显示尺寸，而不是放大到 200% 看。

### 转成 WebP 会丢失元数据吗？

很多转换器默认会去掉 EXIF 等元数据。如果方向、色彩配置或版权信息重要，需要检查转换设置并验证输出。

### 应该给所有浏览器都提供 AVIF 吗？

通过 picture 元素提供 AVIF、WebP 和传统格式回退。不支持 AVIF 的浏览器会自动选择下一个 source，避免旧设备出现坏图。

## 参考资料

- [MDN - 图片文件类型和格式指南](https://developer.mozilla.org/zh-CN/docs/Web/Media/Guides/Formats/Image_types)
- [web.dev - 选择最佳图片格式](https://web.dev/articles/choose-the-best-image-format)
- [MDN - picture 元素](https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/picture)
- [Can I Use - AVIF](https://caniuse.com/avif)

---

- Canonical: https://www.jsonmind.com/zh-CN/guides/choose-webp-avif-png
- Locale: zh-CN
- Published: 2026-11-09
- Updated: 2026-11-09
- Tools: image-compressor, png-to-webp, jpg-to-webp, avif-to-png, webp-to-png