如何压缩网页图片而不牺牲画质
大部分图片体积其实在编码器运行之前就已经浪费掉了。下面这套顺序才是真正能减字节的，以及哪些参数值得在意。
为什么图片体积重要
在大多数网站里，图片是页面体积的单一最大来源 —— 常常超过所有脚本、样式和字体的总和。这带来两个后果：移动网络的访客要多等、还要多花流量；而 图片体积直接决定 LCP（最大内容绘制） —— 性能评分经常就栽在这项 Core Web Vital 上，因为页面上最大的元素通常是首图。
好消息是：图片体积同时也是最容易修的部分，下面这些都不需要重构构建流程。
按影响力排序来动手
压缩工具会诱使你第一时间去拖质量滑块，但那其实是三个杠杆里最小的一个。正确顺序是：
- 缩放 —— 收益遥遥领先。
- 选格式 —— 一次性的、可观的收益。
- 调质量 —— 精细化，收益真实但有上限。
1. 先缩放
一张 4000 像素宽的照片显示在 800 像素宽的位置，携带的像素量是它能显示出来的约 25 倍。这个差距没有任何编解码器补救得了。先发超大图、再狠狠压缩，是典型错误：你付了两次代价，观感还比「一开始就缩放到位」更差。
缩放到实际显示尺寸；如果这张图重要，就按高密度屏幕乘以 2。经验值：整宽首图很少需要超过约 2000 像素宽，正文内嵌图很少需要超过 1200。
2. 选格式
照片走 AVIF 或 WebP；含锐利边缘、文字或透明的图形保留 PNG 或无损 WebP。格式指南里有详细取舍；简短版是：格式选择是「按图的内容类型」决定，而不是全局统一。
3. 调质量
有损格式的质量是 0–100 的刻度，用来在保真度和体积之间做交换。它不是线性的：从 90 降到 80 常常能省掉三分之一体积却看不出差别，而从 50 降到 40 基本只是在制造可见噪点。
几个可用的起点：
| 内容 | 大致目标 | 说明 |
|---|---|---|
| 网页照片 | JPEG/WebP 质量 ~75 | 通常是甜点位；AVIF 达到同等观感的质量值更低 |
| 缩略图、头像 | 质量 60–70 | 显示尺寸小，能掩盖的比你以为的多 |
| 截图、界面、文字 | 无损（PNG / 无损 WebP） | 任何有损压缩都会糊掉 1 像素的边和字形 |
| 归档 / 印刷 | 质量 90+，或用原图 | 保留原文件；这本来就不是网页交付场景 |
按显示尺寸判断，而不是放大看。把压缩后与原图放在它们实际呈现的大小下比较。在 400% 缩放下触目惊心的差异，放到真实场景里往往完全看不出来。
能规模化的批量流程
- 把素材收进一个文件夹 —— 截图、照片、导出图。
- 分成两组：照片类与图形类。它们的格式和质量设置完全不同。
- 各自缩放到交付尺寸。
- 照片类压成 AVIF 和 WebP；图形类用无损压缩。
- 逐个和原图对比。变大的直接弃用 —— 那是信号，不是失败。
- 保留原图。压缩产物是构建产物，原图才是归档。
tinyimg能一次处理最多 30 个文件，并在一次运行里输出多种格式，方便直接对比体积。在浏览器里批量处理还有个附带好处：一整个文件夹的客户照片或个人照片从不离开你的机器 —— 如果你的场景对上传有顾虑，这一点很有价值。
最悄悄浪费字节的几个错误
- 所有设备都发同一张大图。单独一张 2000 像素 JPEG 不叫响应式。用
srcset让手机取更小的版本。 - 反复另存 JPEG。每一代有损编码都会叠加上一次损伤。永远从原图重新编码。
- 照片用 PNG。常常比 JPEG 大 5–10 倍，观感却没有任何好处。
- 为了「最小」压过头。省 40% 很优秀；省 45% 但天空出现色带，就不值得。
- 忘了懒加载。首屏以下的图片不该阻塞首次绘制。懒加载只改一个属性，效果却很大。
- 从不复测。定个体积预算，然后定期检查 —— 否则它会一个素材一个素材地悄悄涨上去。
怎么算做完了
定一个页面预算并守住它。对内容页来说，把图片总载荷控制在约 1 MB 以内是合理目标，其中首图占大头。如果某页远超这个数，常见元凶就三个：没缩放的首图、以 PNG 存储的照片、或者几张本可以用 SVG / CSS 实现的装饰性图片。
这套流程不性感但很短：缩放、选格式、设一个合理的质量、按显示尺寸核对、保留原图。按这个顺序做，几乎能在任何站点上消掉绝大多数本可避免的图片体积。