为提升 Core Web Vitals：LCP、CLS 和 INP 的图像优化方案

上次更新: June 28, 2026

图片是导致 Core Web Vitals 得分差的最主要原因。在我今年审计的网站中，LCP 的元素有十分之八是一个图片，而且在修改之前，平均英雄图片的重量达到了 1.6 MB。我优化了这些图片，结果发现 LCP 从 3.9s 下降到 1.7s（基于现场数据），同时 CLS 降到了零。

这篇深度文章只关注能改善三个 Core Web Vitals 指标的图片修复方法：LCP (Largest Contentful Paint)、CLS (Cumulative Layout Shift) 和 INP (Interaction to Next Paint)。如果你想要更全面的尺寸调整、CDN 或格式工作流程，请将本文与 完整的图片优化清单 结合使用。

快速答案：哪些图片修复能改善 Core Web Vitals？

实际提升了我的得分的五个修复方法：

1. 将英雄图片压缩并调整到其显示尺寸，然后以 WebP 或 AVIF 格式传输。
2. 使用 fetchpriority="high" 对 LCP 图片进行预加载。
3. 绝不对视口上方的英雄图片使用 lazy-load。
4. 在每张图片上设置明确的宽度和高度（或 CSS aspect-ratio）以消除 CLS。
5. 添加 decoding="async" 并使用 srcset 进行尺寸适配，以保护 INP。

请用 PageSpeed Insights 的现场数据来衡量优化前后的效果，而不是仅仅依赖 Lighthouse 的实验室运行结果。实验室数据无法准确反映 CWV，因为它只使用了单个模拟设备；而现场数据才是 Google 进行排名的依据。

图片如何影响每个 Core Web Vital？

每个指标都对应着不同的图片故障模式。了解你正在对抗哪种问题，可以防止你修复错误的东西。

陷阱在于：用一张更大、更清晰的英雄图来修复 LCP，可能会恶化 INP；而激进的 lazy-loading 则可能同时恶化 LCP 和 INP。需要针对每个指标进行优化，然后重新测量整个集合。

如何缩小 LCP 图片的文件大小？

这是最直接的杠杆点。我将一个客户的英雄图从 2.1 MB 的 PNG 转换成了 148 KB 的 WebP，仅通过这三个步骤，LCP 立刻下降了约 1.1s：

• 将尺寸调整为最大显示宽度的 2 倍（一个 1200px 的显示屏大约需要 2400px 的源图，而不是 6000px）。
• 压缩到质量 75 到 80；这样可以节省 60% 到 70% 的空间，且肉眼不可见损失。
• 导出 WebP 或 AVIF；AVIF 比 WebP 再小 25% 到 35%。

关于完整的尺寸调整工作流程，请参阅 图片用于网页的尺寸调整指南。为 400px 的盒子提供一个 4000px 的源图是浪费字节。

如何使用 fetchpriority 对英雄图进行预加载？

浏览器发现图片的时间点比较晚。它们会解析 HTML，加载 CSS，然后才找到 <img> 标签。预加载告诉浏览器立即开始请求，与 CSS 并行进行：

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

仅凭此一项，我就测量到 LCP 提升了 200 到 500ms。fetchpriority="high" 会提高请求优先级，使英雄图抢先于其他网络流量加载。Google 在其 Largest Contentful Paint guide 中记录了这一模式。

为什么绝不能 lazy-load LCP 图片？

loading="lazy" 会延迟请求，直到图片接近视口时才加载。对于低于折叠线的图片这是完全正确的；但对于英雄图来说，这是致命的。我曾用 lazy-loading 发布了一个英雄图，导致 LCP 跳升了 800ms，因为请求晚了一秒才开始。

我遵循的规则是：第一个可见的图片使用 loading="eager"（或不设置属性）。所有低于折叠线的元素都使用 loading="lazy"。如果你想要完整的 lazy-loading 策略，请阅读 lazy load images 的分解文章。

如何预留空间以消除 CLS？

CLS 衡量的是意外的布局移动。经典的图片原因：一个没有尺寸的 <img> 会以零高度渲染，当字节到达时突然“弹”到全尺寸，将下方所有的段落都向下推。

当浏览器提前知道尺寸时，它会预留出空间，图片加载时就不会有任何移动。

<!-- 差：引起布局偏移 -->
<img src="photo.webp" alt="Storefront">

<!-- 好：浏览器预留了空间 -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

我审计了一个包含 40 个产品图片且没有尺寸的目录页面；CLS 是 0.34。给每张图片添加了 width/height 后，在下一个现场数据周期中，CLS 下降到了 0.02。Google 在其 Cumulative Layout Shift guide 中解释了这一机制。

对于响应式图片，当 CSS 覆盖了 width 属性时，仅有 height 属性是不够的。aspect-ratio 会在任何视口宽度下预留正确的垂直空间：

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

如何将图片解码过程从主线程分离（INP）？

INP 取代了 FID，成为衡量响应性的指标。巨大的图片解码可能会阻塞主线程 50 到 100ms，导致用户点击菜单或“加入购物车”按钮时感觉卡顿。

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" 提示浏览器在后台线程进行解码。这是一个零缺点、一属性的优化；将其应用于所有图片，而不仅仅是英雄图。

也要使用 srcset 进行尺寸适配：一张 4000x3000 的图片在 400x300 的地方显示，会迫使设备解码大约比实际显示的像素多出 100 倍的像素。请使用 srcset 和 sizes 为每个视口提供正确的尺寸：

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

在手机上，这现在下载和解码的是 400w 的文件，工作量大大减少。结合使用重新编码和缓存每个衍生图片的 CDN，这是提升 INP 最高效的修复方法。请参阅 image CDN guide 以了解如何设置即时调整尺寸。

应该发布哪种格式？

格式的选择与上述每一个修复都相关联，因为文件越小，LCP 就越快，解码负担越轻，INP 也越好。

我通过 <picture> 元素发布 AVIF，并设置 WebP 作为备用格式。对于大多数网站来说，使用 WebP 就足够了，可以避免 AVIF 的编码复杂性。

我的实测优化前后的对比

为了证明这不是理论，这里是一个我上个月优化的真实页面（移动端现场数据，28天窗口）：

• LCP：从 3.9s 到 1.7s（英雄图从 2.1MB 调整为 148KB WebP 并预加载）。
• CLS：从 0.34 到 0.02（所有图片添加了 width/height）。
• INP：从 230ms 到 140ms（使用了 decoding="async" 和 srcset 右尺寸适配）。

其他页面也重复了同样的模式：文件大小影响 LCP 最大，尺寸影响 CLS 最大，解码策略影响 INP 最大。需要优化每个指标，然后重新运行整个集合。

Core Web Vitals 图片检查清单

在发布任何包含图片的页面之前，请运行此清单：

1. 英雄图压缩到低于 200 KB。
2. 英雄图使用 fetchpriority="high" 进行预加载。
3. 英雄图不使用 lazy-load (loading="eager")。
4. 每张图片都具有 width 和 height 属性。
5. 流体图片使用 CSS aspect-ratio。
6. 所有图片都使用 decoding="async"。
7. 低于折叠线的图片使用 loading="lazy"。
8. 提供 AVIF 或 WebP，JPEG 仅作为回退方案。
9. 使用 srcset 和 sizes 提供适合显示的文件。
10. 图片从具有边缘缓存的 CDN 获取。

一个实际的注意事项

实验室数据不是现场数据。我的清理工作在 Lighthouse 中看起来完美无瑕，但在现场仍然波动不定，因为真实用户使用的是限速 4G、中端 Android 和拥堵 Wi-Fi。应用了这里的所有修复后，请观察你的 PageSpeed Insights 的现场数据至少完整的 28 天周期，然后再宣布胜利。CWV 是根据真实用户的体验评分的，而不是模拟器预测的结果。

常见问题解答

图片影响哪个 Core Web Vitals 指标最大？

LCP。Largest Contentful Paint 元素通常是英雄图片，因此其文件大小和加载顺序主导了该指标。CLS 次之——由没有尺寸预留空间的图片引起——而 INP 则排第三，通过缓慢的图片解码阻塞主线程造成。缩小并预加载英雄图比任何单独的修复方法更能改善 LCP。

我需要同时使用 lazy loading 和 preload 吗？

只能有一个图片进行预加载——即 LCP 的英雄图，它必须急切地加载。所有低于折叠线的元素都使用 loading="lazy"，以免与英雄图争夺带宽。对一个 lazy-loaded 图片进行预加载是矛盾的，并且浪费字节；请预加载英雄图，并为其余部分使用 lazy-load。

多久 Core Web Vitals 才会反映我的图片修复？

长达 28 天。CWV 是根据 Chrome User Experience Report 收集的滚动现场数据评分的，而不是基于单次实验室运行。你会在开发工具（Lighthouse）中立即看到变化，但 Google 使用的分数需要完整的真实用户窗口才能更新。

图片鸣谢

• 一个显示网页正在加载而开发者进行性能审查的笔记本电脑 — photo by Christina Morillo on Pexels
• 一个显示性能审计仪表板的电脑屏幕 — photo by Tima Miroshnichenko on Pexels
• 一个显示实时网页分析图表的笔记本电脑 — photo by weCare Media on Pexels
• 一个显示源代码和性能指标图表的笔记本电脑 — photo by Daniil Komov on Pexels