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 元素),优先用
显式提权











