图片压缩不是调低质量参数：从像素预算到浏览器交付

最近排查一个内容页的首屏性能时，我遇到了一个很典型的问题：页面的 HTML、CSS 和 JavaScript 加起来不到 500 KB，但一张直接从设计稿导出的头图却有 4.6 MB。

图片可以正常显示，布局也没有报错，所以它没有被测试流程发现。直到在移动网络下打开页面，才明显看到标题已经出现，头图还在缓慢加载。

这次排查让我重新确认了一件事：图片压缩不是上线前随手点一下“降低质量”，而是从尺寸、格式到浏览器交付的一套完整决策。

一、先减少无效像素，再讨论压缩率

最常见的误区，是把一张 4000px 宽的图片放进最大宽度只有 960px 的容器，然后依赖 CSS 缩小显示：

.article-cover {
    width: 100%;
    max-width: 960px;
    height: auto;
}

CSS 只改变渲染尺寸，不会减少浏览器需要下载的数据。用户看到的是 960px，网络传输的仍然可能是 4000px 原图。

因此，图片压缩之前应该先确定“像素预算”：图片在不同断点下最大会显示多宽？是否需要为高密度屏幕准备 2 倍图？一张正文图片如果最大显示宽度为 800px，通常没有必要保留 5000px 的源文件作为线上资源。

我的处理顺序是：保留原图，裁掉无效区域，生成目标尺寸，再进行压缩处理。先缩尺寸，往往比反复降低质量参数更有效，也更不容易产生明显的块状噪点。

二、格式选择比统一质量参数更重要

不同内容适合不同格式，不能把同一个预设应用到所有资源上。

例如，一张摄影图从 PNG 转为 WebP，收益可能远高于继续压缩 PNG；但带有细小文字的截图如果使用过强的有损压缩，文件虽然更小，信息却变得难以阅读。

所以图片压缩的验收标准不应该只是“减少了百分之多少”，而应该是：在真实展示尺寸下，关键内容是否仍然清楚。

三、压缩完成，不代表交付完成

即使已经得到一张体积合理的桌面图片，直接把它发送给所有设备仍然可能造成浪费。浏览器支持通过 srcset 和 sizes 选择更合适的候选文件：

<picture>
    <source
        type="image/avif"
        srcset="cover-480.avif 480w,
                cover-960.avif 960w,
                cover-1440.avif 1440w">
    <source
        type="image/webp"
        srcset="cover-480.webp 480w,
                cover-960.webp 960w,
                cover-1440.webp 1440w">
    <img
        src="cover-960.jpg"
        srcset="cover-480.jpg 480w,
                cover-960.jpg 960w,
                cover-1440.jpg 1440w"
        sizes="(max-width: 768px) 100vw, 960px"
        width="960"
        height="540"
        alt="文章封面示例">
</picture>

这里有三个容易忽略的点：

1. 每个候选文件都要独立进行压缩处理，浏览器不会自动优化源文件；
2. width 和 height 用来提前保留布局空间，减少页面跳动；
3. sizes 必须与真实布局一致，否则浏览器仍可能选择过大的资源。

加载策略也需要区分。首屏主图通常不应设置 loading="lazy"，否则它可能被延后请求；正文下方的图片则适合懒加载：

<img
    src="detail-800.webp"
    width="800"
    height="600"
    loading="lazy"
    decoding="async"
    alt="产品细节">

图片压缩解决的是传输体积，懒加载解决的是请求时机，两者不能互相替代。

四、建立可以重复的检查流程

对于偶尔上传的博客图片，可以使用浏览器工具处理。例如 ImageCompress 可以作为手动生成压缩版本的一个选项，再通过预览对比结果。涉及内部设计稿、用户资料或未发布产品时，还应先检查服务的文件处理与删除规则，必要时改用本地工具。

无论使用哪种方式，我都会保留下面这份检查清单：

• 图片尺寸是否匹配最大展示区域；
• 格式是否适合图片内容；
• 处理后的小文字、人物边缘和渐变是否正常；
• 移动端是否会下载不必要的大图；
• 首屏主图是否被错误地懒加载；
• 是否设置了明确的宽高和有意义的 alt；
• 浏览器 Network 面板中的实际传输体积是否符合预期。

当图片数量增加后，可以把最大尺寸、输出格式和文件体积上限写进构建脚本或 CI。这样图片压缩就不再依赖发布者“记得处理”，而会成为提交资源时自动执行或自动校验的工程规则。

总结

一张图能打开，只能证明文件有效；它是否适合上线，还要看像素是否过量、格式是否合理、质量是否可接受，以及浏览器是否把正确的版本交付给正确的设备。

完整的图片压缩流程应该是：确定展示尺寸 → 生成候选规格 → 选择合适格式 → 调整质量 → 在真实页面验收 → 检查网络请求。

与其追求一个漂亮的压缩百分比，不如先从页面里最重的一张图开始，记录修改前后的尺寸、体积和显示效果。只要这套判断可以复现，就能逐步变成团队稳定的性能规范。

本作品采用《CC 协议》，转载必须注明作者和本文链接