2026年图片懒加载指南：打造更快速的网页，同时避免LCP性能损失

上次更新时间: June 28, 2026

懒加载（Lazy loading）有助于让图片密集的页面感觉更快，因为浏览器可以在首次渲染期间跳过视口下方的图片请求。但如果使用不当，它也可能会延迟用户立即需要的某张图片：英雄图、产品主图或文章封面，而这些图片正是构成 Largest Contentful Paint (LCP) 的元素。

本指南将展示在哪里使用原生的 loading="lazy" 属性，在哪里应该保持图片“急切加载”（eager），以及如何发布懒加载的图片而不破坏 Core Web Vitals、SEO 或 CDN 的交付效果。

快速答案：如何为图片进行懒加载？

仅对位于第一个视口之外的图片使用懒加载。保持可能的 LCP 图片处于急切加载状态，为每张图片预留宽度和高度，并从可缓存的 CDN URL 提供响应式的 WebP 或 AVIF 文件。

对于纯 HTML，最简单的实现是在视口下方的 <img> 元素上添加 loading="lazy"。不要将其添加到英雄图、产品主图、第一个可见的文章图片或任何必须在用户滚动之前显示的图片上。

如有疑问，请在 Lighthouse 或 Chrome DevTools 中测试页面。如果一个懒加载的图片被报告为 LCP 元素，请移除该图片的懒加载属性，并考虑使用 fetchpriority="high"。

懒加载实际改变了什么？

懒加载改变的是请求的时机。浏览器可以等到用户足够接近才能下载图片。这节省了长页面的带宽，减轻了初始的请求压力，并让 CSS、字体、脚本和可见的图片有更好的机会优先完成加载。

它不会让过大的图片变小。一张 2400 px 的 JPEG 在最终加载后仍然是浪费资源。从一开始就将懒加载与调整大小、压缩和响应式标记结合使用。关于字节减少，请参阅 Image Compression Deep Dive，而关于 srcset 和移动显示尺寸，请参阅 Mobile Image Optimization Guide。

原生的浏览器功能在 MDN 中有记录，它是在 HTMLImageElement.loading 中的 loading 属性上应用于 images 和 iframes。对于现代网站，建议优先使用此浏览器特性，而不是添加 JavaScript 懒加载库。

哪些图片不应该进行懒加载？

不要对定义页面第一印象的图片进行懒加载。常见的错误是将 loading="lazy" 应用于 CMS 模板中的所有图片，因为它看起来像是一个通用的性能修复方案。

请保持以下图片处于急切加载状态：

1. 主要英雄图。
2. 购买按钮上方的产品图片。
3. 在移动设备上接近顶部时出现的文章第一张图片。
4. 在用户交互前必须可见的 Logo 或界面截图。
5. Chrome 报告为 LCP 元素的任何图片。

Google 的 Core Web Vitals 指导将 LCP 视为视口内最大可见内容元素的渲染时间；请参阅 Largest Contentful Paint。当该元素是图片时，延迟其请求是使指标恶化的最快方法之一。

对于模板使用此规则：第一个图片槽应默认设置为 eager，而后续可重复的图片块应默认设置为 lazy。然后根据页面类型进行覆盖，以应对移动截图显示不同的第一个视口的情况。

如何在 HTML 中实现懒加载？

首先使用原生标记：

<img
  src="/images/gallery-chair.webp"
  alt="Walnut chair photographed from the front for a product gallery"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
>

width 和 height 属性与 loading 一样重要。它们允许浏览器在文件到达之前预留布局空间。如果没有保留空间，延迟的图片可能会将文本推到页面下方，从而造成 Cumulative Layout Shift (CLS)。

对于响应式图片，请保持懒加载应用于回退的 <img>：

<picture>
  <source type="image/avif" srcset="/images/gallery-chair-800.avif 800w, /images/gallery-chair-1200.avif 1200w">
  <source type="image/webp" srcset="/images/gallery-chair-800.webp 800w, /images/gallery-chair-1200.webp 1200w">
  <img
    src="/images/gallery-chair-1200.webp"
    alt="Walnut chair photographed from the front for a product gallery"
    width="1200"
    height="800"
    sizes="(max-width: 700px) 92vw, 680px"
    loading="lazy"
  >
</picture>

对于可能的 LCP 图片，使用相反的模式：

<img
  src="/images/product-hero.webp"
  alt="Walnut lounge chair with green cushion on a white studio background"
  width="1600"
  height="1000"
  fetchpriority="high"
>

Google 关于 browser-level image lazy loading 的文章推荐使用原生懒加载，并警告说第一个可见视口中的图片应该正常加载。该建议对于 2026 年的发布仍然是最干净的基础方案。

懒加载如何影响 SEO？

当重要内容在渲染页面中保持可发现时，懒加载对 SEO 是安全的。Google 可以处理现代 JavaScript，但当最终图片 URL 被交互、仅滚动脚本、cookies 或损坏占位符隐藏时，图像 SEO 的效果就会减弱。

对于内容图片，请使用正常的 <img> 或 <picture> 标记。保留描述性的 alt text、可爬取的 CDN URLs 和周围解释图片的文字内容。Image SEO Guide 2026 提供了更广泛的爬取和 alt-text 工作流程。

Google Search Central 的关于懒加载的 JavaScript SEO 指南指出，内容应该在视口中可见时加载，并且不应依赖于用户的操作，例如点击或输入；请参阅 Fix lazy-loaded content。这对图片库、标签页和无限滚动页面是一个有用的安全防护措施。

懒加载能节省多少性能？

节约的性能取决于视口下方有多少图片以及这些文件有多大。在一篇长文章中，浏览器在初始加载期间可能会避免下载大部分主体图片。在一个只有一张可见照片的短产品页面上，懒加载可能几乎没有节省。

我将本文中的四张图编码为本地 WebP 文件，尺寸为发布大小。最终资源每个的大小在 25 KB 到 36 KB 之间，因此这里并没有隐藏一个巨大的字节问题。更大的收益来自于请求时机：封面图立即可用，而后续的图表可以等到读者滚动才加载。

在指责懒加载之前，请遵循以下顺序：

1. 将源图片调整到最大的实际显示槽位。
2. 将照片和混合图形转换为 WebP 或 AVIF。
3. 为移动布局添加 srcset 和 sizes。
4. 保留图片尺寸或宽高比。
5. 保持 LCP 图片处于急切加载状态。
6. 只对视口下方的图片进行懒加载。
7. 通过具有长期缓存的 CDN 发布。
8. 在狭窄的移动视口上测试页面。

如果需要更全面的流程，Complete Image Optimization Checklist 是发布前的良好最终检查。关于 CDN 规则和缓存头，请使用 Image CDN Guide。

发布前应该测试什么？

测试渲染后的页面，而不仅仅是代码。浏览器原生的懒加载阈值是实现细节，一个在桌面设备上运行良好的页面，在 390 px 的移动视口上仍然可能会延迟错误的图片。

运行此发布检查：

• 封面图或英雄图是急切加载的。
• 可能的 LCP 图片没有标记 loading="lazy"。
• 每张图片都有 width 和 height 或稳定的宽高比容器。
• 视口下方的图片使用 loading="lazy"。
• 响应式图片包含真实的 sizes 值。
• CDN 图片 URL 返回 HTTP 200。
• 文件名描述了可见的图片。
• Alt text 具体且没有堆砌关键词。
• Lighthouse 或 PageSpeed Insights 没有将懒加载图片标记为 LCP。
• 移动截图没有大的空白区域或布局跳跃。

对于开发团队，添加一个模板规则：只有重复的主体图片组件默认才应该进行懒加载。英雄组件、产品主媒体和视口上方的编辑图片需要明确的决策。

2026 年懒加载检查清单

懒加载作为图像流程的一个小部分效果最好。它应该在格式、尺寸、优先级、可访问性和 CDN 检查之后进行。

发布前，检查第一个视口并问一个实际问题：如果每个视口下方的图片都等到滚动时才加载，页面是否仍然有意义？如果是，那么懒加载可能正在发挥作用。如果页面以一个空白的英雄槽开始，请先修复优先级，然后再触碰其他任何东西。