当页面感觉缓慢时，开发者通常会先看代码，但瓶颈往往在于媒体库。加载超过四秒的首页通常具有完全正常的 HTML、CSS 和 JavaScript——以及大量未优化的图片。
根据 HTTP Archive 的数据，图片占平均网页总传输大小的 50% 以上。对于媒体密集型网站——电子商务商店、作品集、博客——可能达到 70% 或更多。再多的 JavaScript 优化也无法修复下载 15 MB 未压缩产品照片的页面。
大图片的真正代价
大图片不仅仅会拖慢您的页面。它们会产生一系列问题：
- 页面加载缓慢——用户会放弃加载时间超过 3 秒的页面。每增加一兆字节的图片都会增加加载时间，尤其是在 3G 速度平均为 1–4 Mbps 的移动网络上。
- Core Web Vitals 不佳——Google 的 Largest Contentful Paint（LCP）指标衡量主要内容加载的速度。主图是最常见的 LCP 元素，如果它们很大，您的 LCP 分数会受到影响。
- 搜索排名降低——Google 将页面速度作为排名因素。慢速页面排名较低，这意味着更少的自然流量。
- 更高的带宽成本——如果您为带宽付费（CDN、托管、云服务），提供未压缩的图像实际上是在为用户不需要的数据付费。
- 电池消耗——在移动设备上，下载和解码大图像会消耗大量电池。用户会注意到某个网站耗尽了他们的手机电量。
最常见的错误
在审计了数百个网站后，同样的模式反复出现：
1. 提供全分辨率图像
最常见的错误：上传一张 6000×4000 的照片（12 MB）并在页面上以 600×400 显示。浏览器下载的像素比需要的多 100 倍，然后在渲染过程中丢弃 99%。
修复方法很简单：将图像调整为其将实际显示的最大大小，然后压缩它们。质量 80 的 600×400 JPEG 通常为 30–80 KB，而不是 12 MB。
2. 照片使用 PNG
PNG 是无损的，这意味着它完美地保留了每个像素。对于照片来说，这是浪费——人眼无法区分 PNG 照片和质量 80 的 JPEG，但 PNG 可能大 5–10 倍。
将 PNG 用于具有锐利边缘、文字或有限颜色的图像（Logo、图标、截图）。将 JPEG 或 WebP 用于照片。
3. 不使用 WebP
WebP 在同等质量下产生的文件比 JPEG 小 25–35%，所有现代浏览器都支持它。当 WebP 可用时，几乎没有理由提供 JPEG。
使用 <picture> 元素提供 WebP 并附带 JPEG 回退：
<picture>
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="...">
</picture>
4. 忽略响应式图像
桌面显示器宽 1920px。手机宽 375px。向两者提供相同的图像会浪费移动端的带宽，并在桌面上提供模糊的图像。
srcset 属性允许您提供多种尺寸并让浏览器选择：
<img src="photo-800.jpg"
srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
sizes="(max-width: 600px) 400px, 800px"
alt="...">
压缩图片时应该注意什么
- 选择正确的格式——照片用 JPEG/WebP，图形用 PNG，短动画用 GIF。
- 调整大小后压缩——先将图像调整到显示大小，然后压缩。
- 质量 75–85 通常是最佳点——低于 70 会出现可见伪影，高于 85 浪费带宽。
- 使用渐进式 JPEG——更小的文件，更好的感知加载速度。
- 提供 WebP 格式——比 JPEG 小 25–35%，所有现代浏览器都支持。
CompactJPG 让这一切变得简单：上传、压缩、保存。所有处理在浏览器中完成——快速、私密、免费。