首屏图片加 loading="lazy" 完全无效，浏览器强制立即加载；它仅对滚动后进入视口的非首屏图片生效，错误使用反而拖慢首屏性能。
loading="lazy" 对首屏图片完全无效
浏览器规范明确要求：所有在首屏视口内的 <img> 标签，无论是否写了 loading="lazy"，都会被强制立即加载。这不是 bug，是设计行为。所以别指望加个属性就能压缩首屏资源体积或减少初始请求数。
常见错误现象包括：页面首屏卡顿、FCP（First Contentful Paint）没改善、Lighthouse 报告里“延迟加载首屏图片”仍标红——其实不是你漏写了 lazy，而是它本来就不该用在这里。
- 首屏判定由浏览器运行时完成，依赖设备 DPR、viewport 宽高、滚动位置等，不是按 HTML 顺序数前 N 张图
- 服务端渲染（SSR）或静态生成（SSG）页面中，若首屏图片被服务端注入了
loading="lazy"，也照样被忽略 - Chrome DevTools 的 Network 面板里能看到：首屏
<img src="...">请求发起时间早于DOMContentLoaded，且无延迟
懒加载真正起效的场景和条件
它只对用户需要滚动后才进入视口的图片生效，核心价值是避免非关键资源抢占带宽和解码线程，间接让首屏渲染更顺畅。
典型适用场景：
- 长图文流（如新闻列表、博客正文中的插图）
- 底部轮播图、相关推荐模块
- 折叠区域（
details/accordion）内默认隐藏的图片 - 分页加载的无限滚动列表（后续页图片）
必须满足两个前提才实际推迟请求：
- 图片不在初始视口内（即
getBoundingClientRect().top > window.innerHeight或类似判断成立） - 浏览器支持
loading="lazy"（Chrome 76+、Firefox 75+、Edge 79+；Safari 15.4+ 开始有限支持；IE 全系不支持）
用错 lazy 反而拖慢首屏速度
当 loading="lazy" 被错误地应用于首屏图片，或与 <link rel="preload"> 混用时，可能引发资源竞争，导致关键图片加载被延后。
具体问题：
- 浏览器内部资源调度器会把
preload和lazy当作冲突策略处理，部分版本 Chrome 会出现 preload 被降级或丢弃 - 如果首屏图同时带
loading="lazy"和fetchpriority="high"，后者会被忽略，失去优先级提升效果 - 使用 IntersectionObserver 手写懒加载时，若初始化晚于
DOMContentLoaded，首屏已滚过，部分图片会“闪现加载”，破坏用户体验
正确做法：首屏图片显式声明 loading="eager"，或干脆不写该属性（默认行为就是 eager）。
兼容旧浏览器时 IntersectionObserver 的初始化时机很关键
手写 JS 懒加载必须在 DOM 构建完成前就注册监听，否则首屏滚动就错过第一批触发点。
实操建议：
- 脚本放在
内并加defer，确保在DOMContentLoaded前执行初始化逻辑 - 不要等
window.onload再调用new IntersectionObserver()，此时图片可能已完成加载或已滚动出视口 - 对
data-src图片，需在 observer callback 中检查isIntersecting === true后再赋值img.src，并移除data-src防止重复触发
示例关键片段：
const observer = new IntersectionObserver(entries => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.removeAttribute('data-src');
observer.unobserve(img);
}
});
}, { threshold: 0.1 });
threshold 设为 0.1 表示元素 10% 进入视口即触发，比默认 0 更早响应，避免用户刚看到图片边缘才开始加载。
首屏性能优化是个系统工程，懒加载只是其中一环；它不解决首屏资源下载本身，只管理非关键资源的加载节奏。最容易被忽略的是：首屏图片永远不该加loading="lazy"，而应该靠压缩格式、CDN、响应式 sizes/srcset 和内联关键 CSS 来提速。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
