Web 图像性能审计 - Core Web Vitals 改善实践指南
图像如何影响性能 - 为什么需要图像审计
图像通常占网页总传输量的 50% 以上，是影响页面加载性能的最大因素。系统性的图像性能审计可以发现优化机会，显著提升用户体验和 Core Web Vitals 分数。
为什么需要图像性能审计:
- 图像是大多数网站最大的性能瓶颈
- 未优化的图像直接影响 LCP (Largest Contentful Paint) 分数
- 不当的图像尺寸导致带宽浪费和加载延迟
- 缺少现代格式支持意味着错失 30-50% 的压缩收益
审计的关键维度:
- 格式优化: 是否使用了 WebP/AVIF 等现代格式
- 尺寸适配: 图像是否按显示尺寸提供，是否有响应式支持
- 压缩质量: 压缩级别是否在质量和大小之间取得平衡
- 加载策略: 是否正确使用懒加载、预加载和优先级提示
- 缓存策略: 是否设置了适当的缓存头
审计工具:
- Chrome DevTools (Network 面板、Lighthouse)
- WebPageTest (详细的瀑布图分析)
- PageSpeed Insights (实际用户数据)
- Squoosh (单张图像的格式/质量对比)
审计工具与指标 - 测量什么、如何评估
使用 Chrome DevTools 和 Lighthouse 进行图像性能审计的具体步骤。
Network 面板分析:
- 打开 DevTools → Network → 筛选 Img 类型
- 检查每张图像的传输大小和加载时间
- 按大小排序，找出最大的图像文件
- 检查 Content-Type 头确认实际格式
- 查看是否有 304 响应 (缓存命中)
关键指标:
- 总图像传输量: 理想情况下首屏图像总量 < 500KB
- 最大单张图像: 超过 200KB 的图像应重点优化
- 图像数量: 首屏超过 10 张图像可能需要合并或延迟加载
Lighthouse 图像审计项:
- Properly size images: 检测实际传输尺寸是否远大于显示尺寸
- Serve images in next-gen formats: 检测是否可以使用 WebP/AVIF
- Efficiently encode images: 检测 JPEG 质量是否过高
- Defer offscreen images: 检测首屏外图像是否使用懒加载
实际尺寸 vs 显示尺寸:
在 DevTools 中悬停图像元素可以看到"Intrinsic size"(实际像素) 和"Rendered size"(显示像素)。如果实际尺寸远大于显示尺寸 × DPR，说明图像过大需要缩小。例如: 显示 400×300，DPR 2x，实际应为 800×600。如果实际是 2000×1500 则浪费了大量带宽。
LCP 改善 - 主图优化策略
图像格式选择是性能优化中收益最大的环节。现代格式可以在相同视觉质量下减少 30-50% 的文件大小。
格式效率排名 (相同视觉质量):
- AVIF: 最高压缩效率。比 JPEG 小 50-60%
- WebP: 比 JPEG 小 25-35%。浏览器支持最广泛
- JPEG XL: 与 AVIF 相当的压缩率，但浏览器支持有限
- JPEG: 传统格式，作为回退方案
实施策略:
使用 <picture> 元素提供多格式支持:
<picture> <source type="image/avif" srcset="image.avif"> <source type="image/webp" srcset="image.webp"> <img src="image.jpg" alt="描述"></picture>
质量设置建议:
- AVIF: quality 30-50 (数值低但视觉质量好)
- WebP: quality 75-85
- JPEG: quality 80-85
CDN 级别的格式协商:
现代 CDN (Cloudflare、Fastly、CloudFront) 支持基于 Accept 头的自动格式转换。客户端发送 Accept: image/avif, image/webp，CDN 自动返回最优格式。这简化了实现但需要 CDN 支持。
CLS 防止 - 消除图像引起的布局偏移
响应式图像确保每个设备只下载所需尺寸的图像，避免向移动设备发送桌面级大图。
审计检查点:
- 是否使用了
srcset和sizes属性 sizes值是否与实际 CSS 布局匹配- 提供的尺寸变体是否覆盖了主要断点
- 是否有图像的实际传输尺寸远大于显示需求
常见问题:
- 缺少 srcset: 所有设备下载相同的大图。移动端浪费 60-80% 带宽
- sizes 不准确: 浏览器选择了错误尺寸的图像
- 断点不足: 只有 2 个尺寸变体，中间设备得到过大或过小的图像
- 缺少 width/height: 导致布局偏移 (CLS 问题)
推荐的尺寸变体:
对于全宽图像，建议提供 5 个尺寸: 400w、800w、1200w、1600w、2000w。这覆盖了从小型手机到 Retina 桌面的所有场景。
自动化检测:
使用 resp-image-lint 书签工具可以在任何页面上检测响应式图像问题。它会高亮显示过大的图像和缺少 srcset 的 img 元素。
传输大小优化 - 压缩与交付优化
图像加载策略决定了哪些图像优先加载、哪些延迟加载，直接影响首屏渲染速度。
懒加载 (Lazy Loading):
<img loading="lazy" src="image.jpg" alt="...">
- 对首屏以下的图像使用
loading="lazy" - 浏览器在图像接近视口时才开始下载
- 可减少初始页面加载 40-60% 的图像传输量
- 注意: LCP 图像不应使用懒加载
预加载关键图像:
<link rel="preload" as="image" href="hero.webp" type="image/webp">
- 对 LCP 图像使用预加载，让浏览器尽早开始下载
- 配合
imagesrcset和imagesizes用于响应式预加载 - 过度预加载会适得其反 - 仅预加载 1-2 张关键图像
fetchpriority 属性:
<img fetchpriority="high" src="hero.jpg">
high: LCP 图像，告诉浏览器优先下载low: 非关键图像，降低优先级auto: 默认值，浏览器自行判断
解码策略:
<img decoding="async" src="image.jpg">
允许浏览器异步解码图像，避免阻塞主线程渲染。对非关键图像推荐使用。
持续监控与改善循环 - 构建性能文化
完成审计后，需要建立持续的监控和优化流程，防止性能退化。
自动化检查清单:
- CI/CD 中集成图像大小检查 - 超过阈值的图像阻止部署
- 构建时自动生成 WebP/AVIF 版本
- 构建时自动生成多种尺寸的响应式图像
- 定期运行 Lighthouse CI 监控性能分数变化
性能预算:
- 首屏图像总量: < 500KB
- 单张图像最大: < 200KB (特殊情况 < 500KB)
- LCP 图像加载时间: < 2.5 秒
- 图像导致的 CLS: < 0.05
监控工具:
- Lighthouse CI: 每次部署自动运行性能审计
- Web Vitals 库: 收集真实用户的 LCP、CLS 数据
- SpeedCurve / Calibre: 持续性能监控服务
优化优先级排序:
- 首先优化 LCP 图像 (影响最大的单一指标)
- 然后处理首屏内的其他图像
- 接着优化首屏外的大图像
- 最后处理小图标和装饰性图像
团队协作:
建立图像上传规范: 最大文件大小限制、推荐格式、命名规则。在 CMS 或上传流程中集成自动压缩和格式转换，确保非技术团队成员上传的图像也符合性能标准。