Web 图像性能审计 - Core Web Vitals 改善实践指南
图像如何影响性能 - 为什么需要图像审计
图像通常占网页总传输量的 50% 以上，是影响页面加载性能的最大因素。系统性的图像性能审计可以发现优化机会，显著提升用户体验和 Core Web Vitals 分数。
为什么需要图像性能审计：
- 图像是大多数网站最大的性能瓶颈
- 未优化的图像直接影响 LCP (Largest Contentful Paint) 分数
- 不当的图像尺寸导致带宽浪费和加载延迟
- 缺少现代格式支持意味着错失 30-50% 的压缩收益
审计的关键维度：
- 格式优化：是否使用了 WebP/AVIF 等现代格式
- 尺寸适配：图像是否按显示尺寸提供，是否有响应式支持
- 压缩质量：压缩级别是否在质量和大小之间取得平衡
- 加载策略：是否正确使用懒加载、预加载和优先级提示
- 缓存策略：是否设置了适当的缓存头
审计工具：
- Chrome DevTools (Network 面板、Lighthouse)
- WebPageTest (详细的瀑布图分析)
- PageSpeed Insights (实际用户数据)
- Squoosh (单张图像的格式/质量对比)
先看规模：据 HTTP Archive 的统计，桌面端页面的图像传输量中位数约为 1MB，移动端也达到约 800KB。图像加载迟缓会直接推高 LCP，而 LCP 又会反映到 Google 搜索排名上。除 LCP 之外还有两个指标与图像高度相关：CLS (Cumulative Layout Shift) 衡量布局意外位移的累积量，一旦 <img> 缺少 width/height 属性或 aspect-ratio，图像下载完成的瞬间布局就会跳动；INP (Interaction to Next Paint) 则会在懒加载逻辑或解码处理占住主线程时恶化，表现为用户点击后迟迟没有反应。至于业务侧的量级，据 Akamai 的调查，页面加载每延迟 1 秒，转化率大约下降 7%。
审计工具与指标 - 测量什么、如何评估
使用 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 则浪费了大量带宽。
逐个工具说明其擅长的观测点。Lighthouse (PageSpeed Insights) 是 Google 提供的 Web 性能审计工具，其中「Image Analysis」标签会逐张给出优化余地，并估算改用 WebP 后能省下多少体积。Chrome DevTools 则按面板分工：Network 面板确认图像体积、加载耗时与 HTTP 缓存状态；Performance 面板用于锁定 LCP 元素并测量图像解码所花的时间；Coverage 面板负责揪出根本没被用到的 CSS 背景图；Rendering 面板打开「Layout Shift Regions」后，可以把造成 CLS 的图像直接圈在画面上。若要覆盖全站而非单页，用 Puppeteer 或 Playwright 写一段自定义审计脚本更省力——自动爬取全站图像，把尺寸、格式、压缩率、alt 属性是否齐备一次性查完。
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 支持。
把 LCP 压进 2.5 秒以内，靠的是几个可叠加的手段。默认情况下浏览器要先解析 HTML、发现 <img> 标签才开始下载图像，而 preload 能让下载与 HTML 解析同时起步。尺寸分发交给 srcset 与 sizes：依屏幕宽度和 DPR (Device Pixel Ratio) 挑选最合适的一档。举个反例，移动端只以 375px 宽显示的位置却下发 2,000 px 宽的原图纯属浪费，750px (即 375px × 2 DPR) 就已足够。最后别忘了缓存——设好 Cache-Control 头 (max-age=31536000, immutable) 可以让回访用户完全不必重新下载。
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 元素。
CLS (Cumulative Layout Shift) 量化的是加载途中内容意外错位的程度，Google 以 0.1 以下为「良好」。第一道防线是给所有 <img> 明写 width 与 height：HTML 属性值取像素整数，若还要用 CSS 做响应式缩放，则并用 width: 100%; height: auto;。第二道防线是 CSS 的 aspect-ratio 属性，写成 .hero-image { aspect-ratio: 16 / 9; width: 100%; object-fit: cover; } 之后，空间在图像下载完成之前就已经占好。占位图这一层可按成本递进选择：LQIP (Low Quality Image Placeholder) 把宽 20-40px 的模糊小图 base64 编码后内联；BlurHash 与 ThumbHash 更为高效，仅凭几十字节 (与 base64 内联相比小两个数量级) 的哈希值就能现场生成占位图。若要做艺术指导，即不同设备呈现不同构图，则需在每个断点分别设定与之相符的 aspect-ratio。
传输大小优化 - 压缩与交付优化
图像加载策略决定了哪些图像优先加载、哪些延迟加载，直接影响首屏渲染速度。
懒加载 (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">
允许浏览器异步解码图像，避免阻塞主线程渲染。对非关键图像推荐使用。
质量档位建议按用途分层：首图与作品集照片用 85-90 (JPEG) 保住画质，缩略图和列表图 70-80 即可，背景与装饰性图像即使降到 60-70 通常也看不出问题。断点上常备 320w、640w、960w、1280w、1920w 这 5 档就能覆盖绝大多数设备；DPR 2x 的设备需要显示宽度两倍的图，而 DPR 3x 多数情况下沿用 2x 的那一档就够，因为人眼很难分辨 2x 以上的差异。交付层面，Cloudinary、imgix、Cloudflare Images 这类图像 CDN 允许直接用 URL 参数动态裁切、转格式、调质量，配合基于 Accept 头的自动格式选择 (Auto Format)，即可按浏览器支持情况自动下发最省的格式。协议层还有一招：HTTP/2 Server Push 已不推荐使用，但 103 Early Hints 可以在 HTML 响应之前先送出关键资源的预加载提示——把 LCP 图像的 URL 通过 Early Hints 告知浏览器，下载就能早于 HTML 解析开始。CloudFront 与 Cloudflare 均已支持 Early Hints。
持续监控与改善循环 - 构建性能文化
完成审计后，需要建立持续的监控和优化流程，防止性能退化。
自动化检查清单：
- 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 或上传流程中集成自动压缩和格式转换，确保非技术团队成员上传的图像也符合性能标准。
预算必须落成具体数字才有约束力，例如「首页图像传输量不超过 500KB」「商品详情页不超过 800KB」，再用 bundlesize 或 Lighthouse CI 把预算检查自动化，超标即让 CI 失败。仅有 Lighthouse 的实验室数据还不足以代表真实体验，因此要引入 RUM (Real User Monitoring) 采集字段数据：Chrome UX Report (CrUX)、web-vitals 库，或 Datadog、New Relic 这类商用工具都能持续监控。框架侧不必事事手写，Next.js 的 Image 组件与 Nuxt Image 模块已经自动处理了上述相当一部分工作。最后落到人的层面——用「不上传 2,000 px 以上的图像」「不用 PNG 改用 JPEG/WebP」「必须填写 alt 属性」这类足够简单的条文，把性能意识扩散到整个团队。