前端图片懒加载实战：首屏 LCP 与滚动加载完整流程

图片懒加载听起来很简单：看不到的图片先不加载，滚动到附近再请求。可在真实页面里，如果把首屏主图也延后加载，LCP 反而会变慢；如果所有图片都立即加载，首屏网络又会被挤占。

这篇文章按完整工作流讲解前端图片懒加载：先区分首屏关键图片和视口外图片，再选择浏览器原生懒加载或视口观察方案，最后用 LCP、Network 和滚动体验验证结果。

目标和边界：哪些图片应该优先加载

图片加载优化不是把所有图片都改成懒加载。正确的边界是：

• 首屏主图、商品首图、文章封面等关键图片，应该尽早加载。
• 用户需要滚动后才看到的图片，可以延后请求。
• 非常小的图标或已经内联的资源，不一定需要单独做懒加载。

先说结论：懒加载的目标是减少首屏无关资源竞争，而不是延迟关键内容。页面性能真正要看的是用户第一眼看到的内容是否尽快稳定呈现。

全流程总览：图片加载从首屏到滚动

一条清晰的图片加载链路通常包含五步：首屏主图优先加载，视口外图片放占位，观察视口变化，接近可视区时请求图片，最终渲染完成。

阶段一：首屏主图不要延后

如果首屏最大图片参与 LCP，最好不要把它延后加载。它应该直接出现在 HTML 或首屏渲染结果里。

这里的思路是让浏览器尽早发现关键图片。真正的关键图片可以优先处理；非关键图片再延后。

阶段二：视口外图片再做懒加载

列表、商品卡片、文章推荐位通常在首屏下方。这些图片可以使用原生懒加载：

原生方式成本低，适合大多数普通图片。它的优点是代码简单，浏览器会根据自身策略决定何时请求。

阶段三：用视口观察控制加载时机

如果你需要更精细地控制加载距离，可以用视口观察方案。图片先放占位地址，接近可视区时再替换成真实地址。

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (!entry.isIntersecting) {
      return;
    }

    const img = entry.target;
    img.src = img.dataset.src;
    observer.unobserve(img);
  });
}, {
  rootMargin: "200px"
});

document.querySelectorAll("img[data-src]").forEach((img) => {
  observer.observe(img);
});

rootMargin 可以让图片在进入视口前就开始加载。值太小可能出现滚动空白，值太大又会提前请求过多图片，需要结合页面实际调节。

阶段四：排查 LCP 变慢的原因

懒加载最常见的误区，就是把首屏主图也延后了。结果是页面先出现大块空白，主图请求变晚，LCP 指标反而升高。

排查时可以按这个顺序看：

1. Performance 面板里找到 LCP 元素，确认它是不是首屏图片。
2. Network 面板里查看这张图片的请求开始时间。
3. 如果它请求很晚，检查是否被懒加载、条件渲染或脚本延迟发现。
4. 把关键图片改成优先加载，再观察 LCP 是否下降。
5. 滚动区图片继续保留懒加载，避免首屏资源过多。

我的推荐流程

1. 先标出首屏可见图片，尤其是最大主图。
2. 首屏关键图片直接加载，并设置合理尺寸，避免布局跳动。
3. 首屏下方图片使用原生懒加载。
4. 图片很多或滚动容器复杂时，再使用视口观察方案。
5. 用 LCP、Network 请求时间和滚动空白情况做验证。
6. 上线前用慢网速模拟一次，确认体验稳定。

容易踩坑的地方

• 把首屏最大图也延后加载，导致 LCP 变慢。
• 只设置懒加载，不设置图片宽高，加载后页面跳动。
• 占位图尺寸和真实图比例不同，导致布局抖动。
• 观察距离太近，用户滚动到图片处才开始请求。
• 一次观察太多图片，没有在加载后取消观察。

落地速查表

总结一下：图片懒加载不是一把全局开关，而是一套分层策略。首屏关键图片要优先出现，视口外图片才适合延后；最后用 LCP、请求时序和滚动体验一起验证。这样既能减少首屏资源竞争，也不会让关键内容被误伤。