懒加载非首屏加速万能解药，用错反拖慢首屏；loading="lazy"仅对非首屏图有效，首屏图须用preload，且需避免src与data-src共存触发重复请求。
懒加载不是首屏加速的万能解药，用错地方反而拖慢首屏——关键看资源是否在首屏内、是否被浏览器提前解析、是否触发了重复请求。
loading="lazy" 什么时候会失效甚至起反作用
原生 loading="lazy" 只对非首屏图片生效，且依赖浏览器解析行为。如果图片在 HTML 中写了 src 属性，哪怕同时加了 loading="lazy"，Chrome 等浏览器仍可能在解析阶段就发起请求（尤其当 src 是有效 URL 时）。
- 首屏图片必须写
src，不能只靠 JS 后续赋值；否则白屏或 SEO 抓取失败 - 不要给首屏图加
loading="lazy"：它不会阻止加载，还可能干扰渲染优先级 - 若同时存在
src和data-src，又用 JS 覆盖src，极易触发两次请求（一次解析时，一次 JS 执行时） - 部分低版本 Safari 对
loading="lazy"支持不全，rootMargin行为也不一致
IntersectionObserver 实现懒加载的三个硬性前提
手写 JS 懒加载看似灵活，但绕不开三个底层限制：元素必须已存在于 DOM、必须有可测量的布局位置、监听器必须在滚动前就位。否则会出现“滚到底了图还没动”或“刚进视口就闪一下”。
- 确保目标
img元素已挂载，且未被display: none或visibility: hidden隐藏（getBoundingClientRect()返回值会失真） -
rootMargin建议设为'200px'而非'0px'：提前加载留出缓冲，避免滚动过快时出现空白 - 必须在
DOMContentLoaded后初始化观察器，不能等到window.onload——后者等所有图片、脚本加载完，已错过首屏时机 - 加载成功后务必调用
observer.unobserve(img)，否则持续监听无意义，浪费内存和性能
首屏图片必须走 preload，不是 lazy
首屏关键图片（如 banner、logo、核心商品图）应明确告诉浏览器“现在就要”，用 <link rel="preload">，而不是寄希望于懒加载机制识别或延迟。
立即学习“前端免费学习笔记（深入）”；
- 写法必须带
as="image"，例如：<link rel="preload" href="banner.webp" as="image" type="image/webp"> - 不要用
prefetch替代preload：前者优先级低，Chrome Network 面板里显示为Priority: low，起不到加速首屏作用 - 若图片路径动态生成（如 CMS 插入），无法写死
<link>，则需服务端注入或用fetch()+createImageBitmap()提前解码，但复杂度陡增 - WebP 格式首屏图建议同时提供
<picture>回退，但preload只能指向一个 URL，所以优先预加载 WebP 版本（现代浏览器占比已超 98%）
真正影响首屏速度的，从来不是“要不要懒加载”，而是“哪些资源该在哪个时刻被浏览器看见”。src、data-src、loading="lazy"、preload 这四个属性的组合逻辑，比代码行数更关键。漏掉一个条件，比如忘了删 src 或误配 rootMargin，整个懒加载策略就从优化变成负优化。
