loading="lazy" 只应加在明确“非首屏”的图片上；首屏关键图（如banner、logo、商品主图、头像）必须排除，否则lcp延迟、白屏或闪动风险显著上升。

loading="lazy" 不能用于所有图片，首屏关键图必须排除

直接结论：loading="lazy" 只应加在明确“非首屏”的图片上；banner、logo、商品主图、头像等首屏必现图一旦加上，LCP 很可能延迟，实测白屏或闪动风险显著上升。

浏览器对 loading="lazy" 的判断基于初始渲染时的布局位置 + 滚动预测，并非实时监听。首屏图哪怕 DOM 里写在最前面，若加载稍慢或渲染快于资源就绪，仍可能被跳过首帧加载队列。

• 首屏图片建议显式写 loading="eager"，或干脆不写（默认就是 eager）
• 用 chrome://tracing 或 Lighthouse 的 “Largest Contentful Paint” 详情里能清晰看到哪张图成了 LCP 元素——这张图绝不能加 loading="lazy"
• 服务端渲染（SSR）或静态生成（SSG）页面中，首屏图片的 src 必须是真实 URL，不能是占位符或 data URI，否则即使 eager 也会触发解码延迟

怎么快速识别哪些图算“首屏关键图”

别靠肉眼估算视口高度，用工具定位更可靠。关键不是“物理位置”，而是“是否参与核心内容呈现”。

• 打开 DevTools → Elements 面板，右键任意 <img> → “Scroll into view”，观察是否立即出现在当前视口顶部区域（不含滚动）
• 运行 getBoundingClientRect() 判断：img.getBoundingClientRect().top 且 <code>img.offsetParent !== null 的，大概率属于首屏影响区
• 电商页的“主图”、新闻页的“头条配图”、登录页的“品牌 logo”，即使 DOM 在底部，只要 CSS 定位让它出现在首屏，就按关键图处理

loading="lazy" 对 background-image 无效，别白费劲

loading="lazy" 是 HTML 属性，只作用于 <img> 和 <iframe></iframe> 标签。CSS 中的 background-image: url(...) 完全不受影响，加了也白加。

• 需要懒加载背景图？只能用 JS：存真实 URL 在 data-bg，用 IntersectionObserver 触发 element.style.backgroundImage = `url(${url})`
• 务必提前设置容器宽高或 aspect-ratio，否则背景图加载瞬间会引发布局偏移（CLS）
• 如果背景图是装饰性（如 banner 底纹），优先考虑内联 SVG 或 CSS 渐变替代，彻底规避请求

移动端和弱网下 lazy 效果有限，别指望它救性能

实测数据（中端安卓 + 4G）显示：loading="lazy" 对 FCP 几乎无改善（±50ms 内波动），主要收益在“首屏后 1–3 屏图片总耗时降低 30%–60%”和“总下载量减少 20%–40%”。它解决的是请求数错峰，不是单图加载变快。

• 真正卡顿常来自未压缩的 PNG、缺失 srcset、没设 width/height 导致重排
• 首屏图体积 > 100KB 时，loading="lazy" 加不加都一样慢——先优化格式（webp/avif）、尺寸、CDN 缓存才管用
• 低端机内存紧张时，大量 lazy 图片在滚动中集中触发解码，反而比 eager 更卡，需配合 decode() 预解码（仅限关键图）

实际落地时最容易被忽略的，是“首屏”这个概念随设备、缩放、字体加载而动态变化。一个在桌面端是首屏下方的图，在折叠屏或高 DPR 设备上可能直接进首屏。别信模板化规则，用 getBoundingClientRect() + 真机调试验证。