Web 图像优化清单 - 15 项生产环境可执行项目
为什么需要系统化的图像优化清单
图像通常占网页总传输量的 50% 以上，是影响页面加载速度的最大因素。零散的优化容易遗漏关键项目，系统化的清单确保每次部署都达到最优状态。
图像优化的影响:
- LCP (Largest Contentful Paint) 的主要瓶颈往往是首屏大图
- CLS (Cumulative Layout Shift) 的常见原因是未指定尺寸的图像
- 每减少 100KB 图像大小，3G 网络下加载时间减少约 0.5 秒
清单的使用方式：将这 15 项作为 CI/CD 流水线的检查点，或作为代码审查的参考标准。不必一次性全部实施，按优先级逐步推进。前 5 项 (格式和压缩) 通常能带来最大收益。
数据背景：Web 页面总传输量中，图像平均占 50% 以上。根据 HTTP Archive 的 2024 年数据，移动端页面图像传输量的中位数约为 1,000KB，相当于整个页面的 52%。系统化地推进图像优化后，页面加载时间缩短 40-60% 的情况并不罕见。
与 Core Web Vitals 的关系：在 Google 的 Core Web Vitals 中，LCP (Largest Contentful Paint) 的 75 百分位处于 2.5 秒以内才算“良好”。考虑到 70% 以上的 LCP 元素都是图像，图像优化可以说是直接关系到 SEO 排名的最重要措施。
格式与压缩优化 - 第 1 至 5 项
1. 使用现代图像格式：优先使用 WebP (兼容性 97%+)，对支持的浏览器提供 AVIF (压缩率再提升 20-30%)。使用 <picture> 元素实现格式回退。
2. 设置适当的压缩质量: WebP 质量 75-80 是照片的最佳平衡点。AVIF 质量 60-70 即可达到 WebP 80 的视觉效果。使用 SSIM 指标验证质量而非仅看文件大小。
3. 去除不必要的元数据：剥离 EXIF、IPTC 等元数据可减少 5-50KB。保留版权信息，删除 GPS 和相机参数。Sharp: sharp(input).withMetadata({}).toFile(output)
4. 对 PNG 使用无损优化：对必须使用 PNG 的图像 (截图、图标) 应用 oxipng 或 pngquant 优化。pngquant 有损压缩可减少 60-80% 体积，视觉差异极小。
5. SVG 优化：使用 SVGO 优化 SVG 文件。去除编辑器元数据、注释、隐藏元素。典型压缩率 30-60%。配置：svgo --multipass input.svg -o output.svg
格式与质量的判断基准：照片使用 AVIF/WebP/JPEG，插图和标志使用 SVG/WebP/PNG。尤其是无需透明通道的照片若使用 PNG，仅改为 JPEG 就能减少 60-80% 的文件体积；理想做法是用 <picture> 元素构建 AVIF → WebP → JPEG 的回退链。质量参数方面，JPEG 为 75-85、WebP 为 75-80、AVIF 为 50-65 是通用的最优区间。
元数据与减色：去除 EXIF、XMP、ICC 配置文件 (sRGB 的情况)，用 exiftool -all= image.jpg 可一次性完成。插图类图像通过 pngquant 减色到 256 色，能在没有视觉劣化的前提下减少 60-80% 体积。
动画图像：GIF 动画应转换为 WebP 动画或 MP4 视频。10 秒的 GIF 动画若为 5MB，转为 WebP 动画约 1MB，转为 MP4 则可压到 300KB 左右。
响应式与分辨率优化 - 第 6 至 9 项
6. 提供多种尺寸：为不同屏幕宽度生成多个尺寸变体。典型断点：320w, 640w, 960w, 1280w, 1920w。使用 srcset 和 sizes 属性让浏览器选择最优尺寸。
7. 设置正确的 sizes 属性: sizes 告诉浏览器图像的显示宽度。错误的 sizes 会导致下载过大或过小的图像。示例：sizes="(max-width: 768px) 100vw, 50vw"
8. 考虑设备像素比: 2x 屏幕需要 2 倍分辨率的图像。但 3x 屏幕不一定需要 3 倍 - 2x 通常足够。过高分辨率浪费带宽且视觉差异不明显。
9. 明确指定图像尺寸：始终在 HTML 中设置 width 和 height 属性，或使用 CSS aspect-ratio。这让浏览器在图像加载前预留空间，防止 CLS。
srcset 与 sizes 的写法：像 <img srcset="img-400.jpg 400w, img-800.jpg 800w, img-1200.jpg 1200w" sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 600px"> 这样，为每个断点准确指定显示宽度。
Retina 支持的适度化：提供 2x 分辨率图像时，显示尺寸的 2 倍分辨率就足够。以 600px 宽显示的图像准备 1,200 px 宽即可在 Retina 屏幕上获得足够的清晰度。3x 图像需要 1,800 px，但文件体积会达到 2x 的 2 倍以上，性价比下降。
源图尺寸与美术指导：若 CMS 输出的图像为 4,000 px 宽而实际显示只有 800px，就有 96% 的带宽被浪费。移动端与桌面端需要不同裁切或宽高比时，用 <picture> 元素的 <source media="..."> 为每种设备指定最优图像。WordPress 站点只要重新审视上传时自动生成的缩略图尺寸设置，就能预期大幅改善。
加载策略优化 - 第 10 至 12 项
10. 首屏图像预加载：对 LCP 图像使用 <link rel="preload" as="image">。这告诉浏览器尽早开始下载关键图像，而不是等到 HTML 解析到 <img> 标签。
11. 非首屏图像懒加载：对首屏以下的图像使用 loading="lazy"。原生懒加载无需 JavaScript，浏览器在图像接近视口时自动加载。注意：不要对 LCP 图像使用懒加载。
12. 使用占位符防止布局偏移：在图像加载前显示占位符 (LQIP、BlurHash 或纯色背景)。这改善感知加载速度并防止 CLS。CSS background-color 是最简单的实现。
不要对 LCP 图像懒加载：这是让 LCP 恶化 300-500ms 的典型错误。用 Chrome DevTools 的 Performance 面板确定 LCP 元素，对该图像保持 loading="eager" (默认值)。
fetchpriority 的设置：对 LCP 图像显式设置 fetchpriority="high"，图像会在浏览器的资源优先级队列中被最先获取，LCP 改善 100-300ms。反之，对装饰性背景图和图标设置 fetchpriority="low"，为重要资源留出带宽。
预加载与实测效果：在 <head> 中写入 <link rel="preload" as="image" href="hero.avif" type="image/avif">，让下载尽早开始。实测数据显示，妥当实现第 10 至 12 项的站点，LCP 平均比未实现的站点改善 800ms。
分发与缓存优化 - 第 13 至 15 项
13. 使用 CDN 分发图像：将图像通过 CDN (如 CloudFront) 分发，利用全球边缘节点减少延迟。图像 CDN (Cloudinary、imgix) 还提供实时格式转换和尺寸调整。
14. 设置长期缓存：对带有内容哈希的图像文件名设置 Cache-Control: max-age=31536000, immutable。文件名包含哈希 (如 hero-a1b2c3.webp) 确保内容变更时 URL 也变更。
15. 启用 HTTP/2 或 HTTP/3: HTTP/2 的多路复用消除了合并图像精灵的需要。HTTP/3 (QUIC) 进一步减少连接建立延迟。确保服务器和 CDN 支持现代协议。
额外建议：使用 Accept 请求头进行内容协商，自动为支持 WebP/AVIF 的浏览器提供最优格式。CloudFront 可通过 Lambda@Edge 或 CloudFront Functions 实现。
CDN 的活用：通过 CDN (Content Delivery Network) 分发图像，从离用户最近的边缘节点返回响应。不使用 CDN 时，从东京的服务器到纽约用户的 RTT (Round Trip Time) 约为 200ms，经由 CDN 则可缩短到 20ms 以下。Cloudflare、CloudFront、Fastly 等 CDN 还提供图像的自动优化功能。
缓存头的推荐值：Cache-Control: public, max-age=31536000, immutable (1 年) 是推荐值。文件名中包含哈希 (例：hero-a3f2b1.webp) 可在内容更新时确实地失效缓存。immutable 指令还能省去浏览器的条件请求 (304 响应)，加快重复访问时的显示。
协议与叠加收益：若 HTTP/1.1 的 6 连接限制成为瓶颈，仅迁移到 HTTP/2 就能把图像加载完成时间缩短 30-50%。HTTP/3 (QUIC) 进一步消除丢包时的 Head-of-Line Blocking，提升移动网络下的稳定性。即使已充分压缩图像的站点，引入 CDN 并重新审视缓存设置，也可能再获得 20-40% 的速度改善。
清单的运营化 - 优先级排序与自动化
将清单转化为可持续执行的流程，而非一次性的优化活动。
优先级排序:
- 高优先级 (立即执行)：格式转换 (WebP)、压缩质量设置、LCP 图像预加载、尺寸属性
- 中优先级 (一周内)：响应式图像、懒加载、CDN 配置
- 低优先级 (持续改进): AVIF 支持、占位符、高级缓存策略
自动化集成:
- CI/CD 中集成 Sharp 进行自动格式转换和压缩
- 文件大小阈值检查：单张图像超过 200KB 时发出警告
- Lighthouse CI 自动运行性能审计，图像相关分数低于阈值时阻止部署
- Git hooks 检查新增图像是否已优化
监控与度量:
- 跟踪页面总图像传输量的趋势
- 监控 LCP 时间，识别图像导致的回归
- 定期审计：每月检查是否有新增的未优化图像
中期措施 (1 周内可实现)：第 1 项 (格式选择)、第 6 项 (srcset/sizes)、第 11 项 (fetchpriority) 需要改动模板或构建流水线，但一旦实现，之后的所有图像都会自动应用。
自动化与定期审计：用 lighthouse ci 监控 LCP 分数，低于阈值时阻止部署的机制很有效。把 sharp 或 squoosh-cli 集成进构建流程，自动完成图像的缩放、格式转换与压缩，开发者就不必逐个留意优化。定期审计可利用 unlighthouse (对整站执行 Lighthouse 扫描) 或 WebPageTest 的 API，尽早发现性能回归。