17370845950

loading="lazy"

主要优化首屏以下图片加载，长图文、商品列表及弱网环境下提升显著；首屏关键图启用反而损害LCP，需配合width/height、srcset及preload等协同优化。

在移动端，loading="lazy" 对图片加载性能有**实际但有限的提升**，效果取决于页面结构、网络环境和用户行为，不是“开箱即用就明显变快”的银弹。

哪些场景下提升最明显

该属性主要优化的是**首屏以下图片的加载时机**，而非首屏本身：

• 长图文页（如新闻、博客）：滚动前不加载瀑布流中下方几十张图，减少初始请求数和带宽占用
• 列表页含大量缩略图（如商品列表）：用户大概率只看前几屏，后续图片延迟加载可降低首屏完成时间（FCP）和最大内容绘制（LCP）压力
• 弱网或低端设备：避免一次性触发数十个图片请求导致连接阻塞或内存紧张

哪些情况几乎没效果甚至有害

盲目添加可能适得其反：

• 首屏关键图片（如 banner、头图）加了 lazy：浏览器可能误判为非关键资源，延迟加载导致 LCP 延迟，反而损害核心指标
• 快速滚动或预加载行为强的用户：浏览器来不及触发懒加载，图片“闪现”或短暂空白，影响体验
• 未配合 width/height 或 aspect-ratio：导致布局偏移（CLS），尤其在滚动中加载时更明显

真实数据参考（典型中端安卓+4G环境）

根据 WebPageTest 和 CrUX 实测反馈：

• 首屏时间（FCP）基本不变（±50ms 内波动）
• 首屏后 1–3 屏图片的加载总耗时平均减少 30%–60%，因错峰发起请求
• 页面总资源下载量下降约 20%–40%（取决于非首屏图片占比）
• 内存峰值降低约 10%–25%，对低端机型较明显

更推荐的实践组合

单独用 loading="lazy" 效果平平，需配合其他手段才能释放价值：

• 仅对 明确非首屏 的 添加，首屏图片保持默认 eager
• 务必设置 width 和 height，或用 aspect-ratio 防止 CLS
• 搭配现代格式（webp/avif）和响应式 sizes+srcset，压缩体积比延迟加载更重要
• 对关键路径图片（如 LCP 元素），优先用 显式提权