先看四大差异
| 格式 | 是否无损 | 透明 | 动画 | 典型用途 |
|---|---|---|---|---|
| JPEG | 有损 | 否 | 否 | 照片、连续色调 |
| PNG | 无损 | 是 | 否 | 截图、线条、图标、需透明 |
| WebP | 两者皆可 | 是 | 是 | 网页通用，体积更小 |
| AVIF | 两者皆可 | 是 | 是 | 追求最小体积，编码较慢 |
| GIF | 有损（256 色） | 是 | 是 | 简单动图，色域低 |
| SVG | 矢量 | 是 | 是 | 图标、Logo、线条图 |
质量参数怎么设
- 照片：JPEG 质量 75–85 通常肉眼无损；同样观感下 WebP 比 JPEG 小约 25–35%，AVIF 再小 20–30%；
- 截图 / UI：用 PNG 或 WebP 无损，文字边缘才清晰；
- 图标 / 线条图：优先 SVG，任意缩放不糊；
- 动图：能用视频就别用 GIF，体积和清晰度都更好。
常见坑
- 二次压缩累积损失：反复存 JPEG 会一代代变差，原图务必留无损；
- 透明通道转 JPEG：JPEG 不支持透明，透明区域会变黑底或白底；
- 忽略 EXIF：照片里的拍摄时间、定位可能随文件外泄，发布前建议清除；
- AVIF 编码慢：适合构建期预处理，不适合用户实时上传即时转换。
动手试试
给图片加水印并控制导出质量：图片水印。
实战案例：三次选错图片格式
- 照片存成 PNG：一张照片 PNG 可达数 MB，换成 WebP / AVIF 体积能降一大截。照片类用有损格式，图标与线条图才适合 PNG / SVG。
- 图标用 JPG：边缘出现明显噪点与锯齿，透明背景也丢了。图标应优先用 SVG；位图图标用 PNG 或带透明的 WebP。
- 只换格式不调尺寸：把 4000px 原图直接发给手机，尺寸带来的损耗远大于编码格式的收益。应配合
srcset按视口提供合适宽度。
常见问题（FAQ）
WebP 与 AVIF 怎么选？AVIF 压缩率更高但编码更慢、兼容性稍弱；可用 picture 同时提供 AVIF 与 WebP 回退。压缩到多小合适？按展示尺寸给图，首屏主图控制在 200KB 以内通常可接受，别为体积牺牲观感。要保留原图吗？要，原图是重新导出的唯一来源，压缩产物应可随时重建。怎么避免布局抖动？为图片标注 width / height 或固定宽高比，给加载预留空间。
交付流程与工具链
图片体积问题很少靠临场处理解决，更有效的是把规则固化进构建流程。
- 自动生成多尺寸：在构建或上传阶段自动产出若干宽度档位，配合响应式图片属性按视口选择，避免把原图直接发布到线上。
- 格式回退要显式：用支持多格式回退的标签结构同时提供新一代格式与传统格式，让浏览器自行选择，而不要靠脚本探测后再加载，后者会增加一次请求往返。
- 体积预算纳入门禁：为关键页面设定图片总体积上限，超过则构建失败。把预算写进自动化检查，比在评审中提醒更有效。
- 懒加载要有边界：首屏主图不应懒加载，否则会推迟首屏渲染；折叠以下的图片才应延迟加载，并预留占位尺寸避免布局跳动。
- 关心解码成本：体积小不代表解码快，过大的分辨率即使压缩得很好也会占用较多内存与解码时间，移动端尤其明显。按展示尺寸给图仍然是最重要的一条。
审核与版本管理
压缩产物应由脚本生成而非手工上传，这样重新导出时可以完全复现。原始素材另行归档，并记录每张图的用途与授权来源，避免后续合规问题。
小尺寸场景的取舍
图标与缩略图这类小尺寸素材，格式带来的体积差异往往只有几 KB，此时应优先考虑清晰度与一致性，而不是继续压榨体积。把小图强行压缩到最低质量，会在高分屏上出现明显模糊，反而损害观感。