网页图片压缩：不损失画质的完整流程

图片压缩经常被当成一个质量滑块。实际上，体积的大头由三个更早的决定控制：像素尺寸、文件格式，以及图片本身包含什么内容。

本文给出一套可重复的处理顺序，以及避免“文件小了但体验更差”的检查方法。

图片为什么大

图片体积取决于：

• 像素数量，也就是宽乘高。
• 细节和噪点的多少。
• 格式及其压缩方式。
• 质量参数。
• EXIF、色彩配置等元数据。

一张 4000 × 3000 的照片如果只以 800 × 600 显示，像素数量是布局需要的 25 倍。此时拼命压缩，不如先缩小尺寸。

算一笔账：4000 × 3000、每像素 4 字节，解码后是 48 MB。质量 80 的 JPEG 通常能压到 3 到 6 MB；同一张照片存成 PNG 可能超过 20 MB，因为 PNG 是无损的，而照片里的细节几乎无法重复。细节和噪点与尺寸同样重要：树叶、织物纹理、胶片颗粒消耗的码率远高于平滑天空或纯色背景，所以两张尺寸相同的图片，体积相差五倍并不奇怪。

元数据通常只是零头。EXIF、缩略图和 ICC 配置加起来往往只有几十 KB。删除它们对隐私和整洁有价值，但救不了一张 5 MB 的首屏大图。

第一步：缩放到显示尺寸

先找出图片在页面上的最大显示尺寸，并把高密度屏幕考虑进去。如果布局宽度是 800 CSS 像素，1600 像素宽的源图可以覆盖 2 倍屏。4000 像素宽的源图通常只是浪费带宽。

先缩放，再压缩。然后在显示尺寸下比较效果。一张尺寸正确、看起来清晰的图片，比一张很大却被压坏的图片更好。

高密度屏幕不等于要发原图。它只意味着文件应覆盖 CSS 布局尺寸乘以设备像素比。布局宽 800 CSS 像素的正文图片，在 DPR 1 下需要 800 像素，在 DPR 2 下需要 1600 像素；2400 像素的文件在绝大多数手机和笔记本上都是浪费。应使用 srcset 的宽度描述符配合 sizes 让浏览器自己选，而不是让所有设备都下载最大的候选。

也不要为了填满容器而放大。把 600 像素的图拉到 1200 像素只会增加体积和模糊，不会增加细节。源图太小就缩小展示尺寸，或者换一张更好的源图。

体积差距很直观。800 × 600、质量 80 的 JPEG 通常在 60 到 120 KB；同一张照片放大到 1600 × 1200 后像素数变成四倍，往往落在 250 到 450 KB。从大图开始缩放的收益是双份的：既减少了字节，又保证清晰度，因为浏览器是从干净的源图降采样，而不是从已经压过一遍的文件继续处理。

第二步：选择格式

格式应与内容匹配。截图存成低质量 JPEG，文字边缘会发虚；照片存成 PNG，体积会不必要地大。更完整的对比可以看 WebP、AVIF 与 PNG 的差异说明。

在画质相近的前提下，JPEG 换成 WebP 通常能省 25% 到 35%，WebP 换成 AVIF 往往还能再省 20% 到 40%。这些区间不是承诺：AVIF 在平滑渐变和高分辨率照片上优势最大，遇到很小的图或合成图形时，容器开销反而可能让它更大。代价是编码时间，AVIF 可能比 WebP 慢数倍，批量构建和用户上传场景都要把这段时间算进去。

浏览器支持已经很广，但不是全覆盖。现代 Chrome、Firefox 和 Safari 都支持 AVIF，较旧的嵌入式 WebView 和一些企业浏览器会落后。这正是 picture 回退存在的意义，不要只提供 AVIF 然后期待所有客户端都能解码。

截图应先试无损 WebP，再决定是否必须用 PNG。对界面截图来说，无损 WebP 通常比 PNG 小 20% 到 30%，而且每个像素都不变。颜色很少的简单图表可以用调色板 PNG，体积可能更小。Logo 和图标仍然首选 SVG：矢量图缩放不增加字节，前提是原始素材确实是矢量，而不是把位图塞进 SVG 里。

第三步：在显示尺寸下调整质量

有损编码用细节换体积。评估结果时要在用户实际看到的尺寸下看，而不是放大到 200%。

一个可操作的流程：

1. 先用中等质量编码。
2. 在显示尺寸下与源图比较。
3. 逐步降低质量，直到刚好看得出差异，再退回上一档。
4. 记录文件体积。
5. 对计划上线的每种格式重复上述步骤。

截图、文字和线条图形应使用无损 WebP 或 PNG。有损压缩会在锐利边缘产生振铃，让文字更难读。

质量数字不能跨编码器直接搬。JPEG 的 80、WebP 的 75、AVIF 的 55 可能得到相近的观感，但体积差很多，因为每个编码器对质量刻度定义不同。不要把某个格式的质量值复制到另一个格式，然后假设含义相同。正确做法是先定视觉目标，再编码几个候选版本做对比。

观察重点取决于内容。照片要看平滑渐变是否出现色带、高对比边缘是否出现蚊状噪声，这两类伪影都说明码率偏低。JPEG 通常采用 4:2:0 色度抽样，对肤色影响不大，但会让饱和红色和细彩色线条发糊。质量从 75 提到 90，文件常常增大 1.5 到 2 倍，而多数人在显示尺寸下看不出差别。内容图不值得做这个交换，但允许用户放大的商品图可能值得。

客观指标适合排序，不适合替你做决定。SSIM、VMAF 与照片和视频的主观感受相关性较好，却容易忽略文字伪影。在实际显示尺寸下做一次肉眼 A/B，再设一个体积预算，通常比追求某个单一分数更可靠。

第四步：去掉不需要的数据

图片经常携带网页上并不需要的元数据：

• 相机写入的 EXIF 信息。
• 缩略图。
• 不需要的色彩配置。
• 不应公开的版权或位置信息。

有些转换器默认移除元数据，有些会保留。应检查输出结果。如果准确色彩依赖某个配置，就保留它，并在浏览器中确认效果。

方向是最容易踩的坑。手机照片常常按一个方向存储像素，再用 EXIF 的 Orientation 标记告诉阅读器旋转。如果先删元数据、后应用旋转，图片就会横过来。多数浏览器端编码器在解码时会自动应用方向，命令行工具和较旧的库不一定。批量处理前先拿一张竖拍照片试一遍。

ICC 配置通常只有一到三 KB，广色域配置可能更大。图片只用于网页、转成 sRGB 后颜色也正常时，转换并去掉原配置是安全的。品牌色需要和印刷参考对齐时，应保留配置，并且除了 Chrome 还要在 Safari 里检查，因为不同浏览器和操作系统的色彩管理并不一致。

第五步：用回退方案提供现代格式

使用 picture 元素，可以同时提供现代格式和旧浏览器回退：

<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"
    fetchpriority="high"
    decoding="async"
  />
</picture>

img 负责回退和替代文本。设置 width 和 height 可以预留空间，避免布局偏移。

浏览器按顺序检查 source，选择第一个它支持的 type，所以 AVIF 放最前、WebP 其次，JPEG 留在 img 里。浏览器不会替你比较文件大小。需要响应式宽度时，还要在每个 source 上同时写 srcset 和 sizes，否则手机可能和桌面下载同样大的 1600 像素 AVIF。type 属性才触发格式协商；漏掉它，浏览器会老老实实下载一个它根本解不了的格式。

不要预加载所有候选。给三种格式都加 preload，会让浏览器请求永远用不上的文件。只预加载 LCP 那张图，而且只预加载大多数流量会选中的格式，或者干脆让预加载扫描器自然发现 img。回退 img 上的 fetchpriority="high" 通常已经足够。

与 Core Web Vitals 的关系

图片会直接影响最大内容绘制和累积布局偏移：

• 首屏主图应以现代格式、正确尺寸提供。
• 首屏主图不要懒加载，应使用 fetchpriority="high"。
• 设置宽高或宽高比，避免布局跳动。
• 避免超大图片与交互任务争抢资源。

如果图片模糊，或者浏览器需要下载多个候选源，那么文件变小并不等于体验变好。最终要以真实页面的测量结果为准。

把字段阈值当作护栏：多数访问的 LCP 应不超过 2.5 秒，CLS 应低于 0.1。商品图、横幅和文章头图经常就是 LCP 元素，因此它们的字节数和被发现的时间同样重要。对首屏主图做懒加载会把发现时间推迟到布局之后，是最常见的自伤式 LCP 退化。首屏以下的图片则相反，懒加载通常是对的。

decoding="async" 让图片解码不阻塞布局，但它不是加载优先级。它不会让大图更早到达。反过来，只写 loading="eager" 也不保证优先级；真正重要的那一张图应同时加 fetchpriority="high"。不要给轮播里的五张图都设高优先级，互相竞争的提示会彼此抵消。

CLS 预防比修复容易。用 width 和 height 或 CSS aspect-ratio 预留空间，图片加载完成时就不会触发重排。如果图片会被插入没有固有尺寸的容器，至少给它一个最小高度兜底。

验证结果

压缩完成后检查：

1. 图片在显示尺寸下是否清晰。
2. 文字和锐利边缘是否可读。
3. 透明背景是否保留。
4. 色彩配置和方向是否正确。
5. 文件体积是否确实减小。
6. 页面是否仍然通过 Core Web Vitals 检查。

图片压缩工具可以在浏览器中完成缩放和压缩，不需要上传文件。PNG 转 WebP和 JPG 转 WebP用于转换格式，需要兼容源文件时可以用 AVIF 转 PNG。如果下游工具不接受 WebP，可以用 WebP 转 PNG转换。

验证时关闭浏览器缓存并开启网络限速，因为本地缓存的 2 MB 图片和 40 KB 图片感觉完全一样。在 DevTools 元素面板里确认实际渲染尺寸，如果受众使用高密度屏，再按 DPR 2 检查一遍。除了 Chrome，还要在 Safari 和 Firefox 里打开，色彩配置和 AVIF 解码可能不同。最后重点看渐变和文字边缘，这两处最先暴露压缩伪影。

常见错误

• 直接压缩 4000 像素的图片，而不是先缩放。
• 用 JPEG 保存带文字的截图。
• 用 PNG 保存大尺寸照片。
• 放大到 200% 判断画质。
• 删除色彩配置导致颜色变化。
• 忘记设置宽高，造成布局偏移。
• 对首屏主图做懒加载，拖慢 LCP。
• 对已经压过的 JPEG 再压一遍，多损失一代细节。

压缩是一连串决定，而不是一个滑块。先缩放，再选格式，在显示尺寸下定质量，最后验证结果。

也有不适用的场景。图片小于 10 KB 时，容器和元数据开销可能超过换格式的收益，保持原样更划算。CDN 或图片服务已经能从一次上传自动协商 AVIF 和 WebP 时，不要手工生成所有变体，否则既重复劳动，又容易和源文件不同步。页面以文字为主、图片只是装饰时，优化一个 12 KB 图标不会改变 LCP，精力应放在字体和脚本上。医学影像、档案扫描这类要求像素值精确的场景，有损压缩根本不是画质取舍；应使用无损格式并校验哈希，而不是靠肉眼拖滑块。