原生 loading="lazy" 是当前最轻量、兼容性足够好的首选方案，Chrome 76+、Firefox 75+、Safari 15.4+ 均已支持，无需额外 JS，不阻塞渲染，也不增加 bundle 体积。

图片懒加载该用 loading="lazy" 还是 JS 实现？

原生 loading="lazy" 是当前最轻量、兼容性足够好的首选方案。Chrome 76+、Firefox 75+、Safari 15.4+ 均已支持，且无需额外 JS，不阻塞渲染，也不增加 bundle 体积。

JS 懒加载（如 IntersectionObserver）仅在需兼容老浏览器、或要配合自定义占位、渐入动画、或触发非图片资源（如 iframe、视频）时才必要。

• loading="lazy" 对 和 生效，对 background-image 无效
• 它默认只对「视口下方」的图片生效；若图片初始就在视口内（比如首屏大图），会立即加载，无需干预
• 不要给所有图片都加——loading="eager" 显式声明首屏关键图，避免被误懒加载

IntersectionObserver 懒加载的关键参数怎么设？

用 JS 实现时，IntersectionObserver 的 rootMargin 和 threshold 直接影响加载时机和用户体验。

const observer = new IntersectionObserver(
  (entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        img.classList.remove('lazy');
        observer.unobserve(img);
      }
    });
  },
  {
    rootMargin: '100px', // 提前 100px 开始加载，避免滚动过快时白屏
    threshold: 0.01     // 只要 1% 进入视口就触发，比 0 更可靠
  }
);

• rootMargin: '100px' 比 '0px' 更实用：用户快速滚动时，图片能在进入视口前就发起请求，减少空白感
• threshold: 0.01 避免用 0——某些浏览器对完全未相交的判定有延迟，容易导致“卡一下才加载”
• 务必在加载完成后调用 observer.unobserve(img)，否则重复回调、内存泄漏风险明显

懒加载后图片闪烁或错位怎么办？

本质是图片尺寸未预留，加载完成前高度塌陷，引发布局抖动（layout shift）。这不是懒加载本身的问题，而是 HTML/CSS 配合缺失。

• 始终为 设置明确的 width 和 height 属性（非 CSS），浏览器可据此计算原始宽高比，保留占位空间
• 用 aspect-ratio CSS 属性兜底：img.lazy { aspect-ratio: 16/9; }，现代浏览器兼容良好
• 避免用 background-image + padding-top 模拟宽高比——它无法被 loading="lazy" 识别，且 JS 懒加载时难以同步控制背景图加载
• 如果使用响应式图片（srcset），确保 width/height 与最大尺寸匹配，或用 sizes 配合 aspect-ratio

WebP + CDN 缓存对懒加载速度的影响有多大？

懒加载只是“何时发起请求”，真正决定加载快慢的是资源体积和传输链路。WebP 和 CDN 不改变懒加载逻辑，但能大幅缩短请求完成时间，让“懒”得更顺滑。

• 同一张图，WebP 比 JPEG 小 25–35%，尤其对带透明度或渐变的图效果更明显；用 回退保障兼容：

  
    
    @@##@@
  

• CDN 缓存命中率低，会导致每次都是回源拉取——确认 CDN 配置了对 .webp 和 .jpg 的缓存规则，且 Cache-Control 头合理（如 public, max-age=31536000）
• 注意：CDN 若未开启 Brotli/Gzip 压缩，或未配置 Vary: Accept，可能把 WebP 资源错误缓存并返回给不支持的旧浏览器

懒加载本身不解决体积和网络问题，但它是释放 WebP 和 CDN 效能的前提——没被懒加载的图，再小再近也白搭。