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" 效果平平，需配合其他手段才能释放价值：
- 仅对 明确非首屏 的
<img>添加，首屏图片保持默认 eager - 务必设置
width和height，或用aspect-ratio防止 CLS - 搭配现代格式（
webp/avif）和响应式sizes+srcset，压缩体积比延迟加载更重要 - 对关键路径图片（如 LCP 元素），优先用
<link rel="preload">显式提权
