网站图片怎么压缩：五步让网页更快

根据 HTTP Archive 的《2025 Web Almanac》，手机端首页体积的中位数是 2.56 MB，其中图片占 911 KB；桌面端页面里图片的中位数是 1,058 KB。图片也是访客最先等待的内容：页面加载时屏幕上最大的元素，也就是“最大内容绘制”（LCP），在 76% 的手机页面上是一张图片。

图片越轻，在慢速网络下打开越快，访客消耗的流量越少，你的带宽费用也越低。LCP 是 Google 核心网页指标（Core Web Vitals）之一，Google 用这些指标评估页面体验，所以图片过重的代价不只是让人多等几秒。

压缩救不了一张远大于显示位置的图片。一张 4000 像素宽的相机照片，放进 800 像素宽的栏里，像素数是页面实际用得到的 25 倍。web.dev 指出，把桌面尺寸的图片发给手机，可能多消耗 2–4 倍的流量。

• 通栏横幅：大多数版面约 1600–2000 像素宽就够了。
• 文章栏里的图片：约为栏宽的两倍，在高分辨率屏幕上也能保持清晰（例如 700 像素宽的栏用 1400 像素）。
• 缩略图和头像：显示尺寸的两倍，通常是 200–400 像素。

格式决定了一张图片能存得多高效。简单来说：照片适合 JPG 或 WebP；标志、截图和带透明背景的图片适合 PNG 或 WebP。我们的JPG、PNG、WebP 对比详细说明了每种格式在什么情况下更好。

目前约 97% 正在使用的浏览器都能显示 WebP，而且它往往明显更小。想试试的话，用JPG 转 WebP或PNG 转 WebP转换，再和原图比较：转换后的文件不一定更小，简单的图形尤其如此。

压缩会去掉肉眼不太会察觉的数据。在 Bitinz 图片压缩页面，你可以一次拖入一批 JPG、PNG 或 WebP 文件，并选择三个档位之一：

• 快速：速度优先，适合大批量图片。
• 均衡：默认档位，适合大多数网站图片。
• 极致：多花一点时间，换来更小的文件；值得用在每个页面都会出现的图片上，比如横幅和背景。

保持原格式时，Bitinz 返回的文件绝不会比你上传的更大。请在原始尺寸下对比压缩结果和原图，尤其是带细小文字或平滑渐变的图片，满意后再下载。

即使图片压缩得很好，如果加载的时机或尺寸不对，页面照样会变慢。几个 HTML 属性就能解决大部分问题：

• 给每张图片设置 width 和 height，让浏览器预留空间，加载时版面不会跳动。
• 给页面下方的图片加上 loading="lazy"，访客滚动到附近时才加载。
• 页面顶部的主图千万不要懒加载。web.dev 建议给这张图加上 fetchpriority="high"，而且最多只用在一两张图片上。
• 用 srcset 和 sizes 为同一张图提供几种宽度，让手机下载比大屏幕更小的文件。
• 为图片设置较长的缓存时间，有 CDN 就通过 CDN 分发，让回访的访客不必重新下载。

用 PageSpeed Insights 或 Chrome 里的 Lighthouse 面板测一下页面。从 Lighthouse 13 开始，图片相关的检查合并成了一项名为“Improve image delivery”的洞察，会列出还能进一步压缩、改用新格式或缩小尺寸的图片。预计节省不到 4 KiB 的图片不会被列出，所以列表越短越好。

然后自己用手机看一遍页面。锐利的边缘、图片里的文字和肤色，最先暴露压缩问题。

如果你的网站每天都在新增图片，比如通过内容管理系统或网店上传，就应该在上传或发布环节自动压缩，而不是手动处理。Bitinz 开发者 API 通过 HTTP 接收图片，并返回压缩后文件的链接，可以在脚本或构建流程里运行。每个账户每月都有免费额度。

1. 01把每张图片缩放到显示尺寸的两倍左右。
2. 02照片用 JPG 或 WebP，图形和透明背景用 PNG 或 WebP。
3. 03用均衡档压缩，最大的几张图试试极致档。
4. 04替换之前，先把压缩结果和原图对比一遍。
5. 05设置 width 和 height，首屏以下的图片懒加载，主图绝不懒加载。
6. 06再用 PageSpeed Insights 检查一次页面。

图片要上传到自己网站以外的地方？每个平台都有自己的规则，请看邮件与电商平台的图片尺寸要求。