图片压缩能省多少移动流量：实测口径与测算方法

2026-10-05

图片压缩和移动流量的关系，比多数人想的更直接。一次典型的新闻浏览或电商浏览里，图片通常是传输字节里占比最大的一项，大致在页面总量的一半到四分之三之间。压缩图片是唯一一项不动排版、不动文案、不动功能，却能真的把流量账单压下来的改动。

不过大家最想要的那个数字，也就是到底能省多少，没有通用答案。它取决于你的图片内容、图片是怎么产出的，以及页面现在已经在做什么。这篇给的是测量方法和实践中常见的区间，让你算出自己的数字，而不是借别人的。

移动流量到底花在哪

压缩之前，先搞清楚字节被谁用了。在这里靠猜，往往会让人去改错的对象。

• 用 Chrome DevTools 打开页面，切到 Network 面板，按 Img 过滤。要看的是 transferred 那一列，不是 resource size。
• 连续刷新三次取中位数。单次采样会把缓存和懒加载的噪声一起带进来。
• 把首屏图片和其余图片分开统计。懒加载配置错误时，折叠线以下的字节照样会加载，这种情况很常见。
• 检查同一张图是否被以不同尺寸下载了两次。重复请求是纯浪费，在移动版模板里出现频率很高。
• 字体和视频单独看。如果这两项压过了图片，那压图片帮不上多少忙。

一张图能省多少：按格式与场景分

以下是在合理尺寸下、用真实照片内容测出的粗略区间，用来建立量级感，不能直接当成你的结果。

• 相机原始分辨率的 JPEG 照片：通常能减掉四到六成，原图直接来自手机时还会更多。
• 已经被压缩过一次的 JPEG：百分之五到二十。对压缩过的文件再压一次收益很小，还要付出可见的画质代价。
• 纯色为主的 PNG 截图：五到八成，而且换成 WebP 或 AVIF 往往比继续压 PNG 更划算。
• PNG 存的照片：节省幅度非常大，因为 PNG 本来就不适合装照片类数据。
• 已经在用 WebP：换到 AVIF 还能再省一到三成，代价是编码时间变长。
• 先改尺寸再压缩，通常比只调质量更管用。把边长减半就能先砍掉约四分之三的字节，质量滑块这时还没开始发挥作用。

为什么你的压缩率和别人的不一样

三个变量解释了公开数据和你实测结果之间的大部分差距。

• 画面复杂度。街景包含的细节远多于靠墙的人像，在同样的质量设置下压缩率更差。
• 源文件历史。相机直出的 JPEG 已经压过一次，TIFF 扫描件没有，扫描件能省的多得多。
• 目标尺寸。先缩放再压缩的压缩率看起来很漂亮，其中一部分功劳其实是缩放的。两步要分开测。

把省下的 MB 换成有人关心的数字

算法很简单：月访问次数乘以每次访问的平均图片字节数，再乘以压缩率。一个月 2 万次移动访问、每次 1.4MB 图片的站点，就是 28GB。压缩掉一半，每月省 14GB。

这算不算有意义，取决于读者的套餐。在 5GB 的限量套餐上，14GB 分摊到一批用户身上，是实实在在解掉了一个限制；在家庭无限宽带上它几乎看不见，那时诚实的理由是速度而不是费用。弱网下的加载速度，才是压缩无论套餐如何都能带来收益的地方。

读者能做什么，站长能做什么

读者这边选项不多，但确实存在：打开浏览器的省流量模式；调低聊天应用里的图片质量设置，多数应用默认值远高于手机屏幕实际需要的水平；大图册尽量在 Wi-Fi 下下载。

站长这边可以动的空间大得多。

• 先把像素尺寸限制到展示位的实际大小，再压缩。这一步要最先做。
• 用 WebP 或 AVIF 并提供回退，不要对所有设备都发同一张 JPEG。
• 折叠线以下的图片做懒加载，同时把最可能成为 LCP 的那张排除在懒加载之外。
• 在上传或构建阶段、于浏览器内完成压缩，既不用部署新服务，文件也不会经过服务器。

顺序错了会白做。先缩放再压缩，先测 transferred 再决定要不要压，先确认图片确实是消耗大头再投入时间。这三步做完，剩下的就是按自己的实测数字写结论。延伸阅读：/blog/compress-jpg-under-100kb 讲的是目标大小模式怎么设，/blog/image-compression-affects-page-speed 讲的是字节和速度之间的关系。