懒加载不提升首屏速度，反而可能拖慢——需禁用首屏图的loading="lazy"、用eager或不设属性，早于domcontentloaded初始化intersectionobserver，并避免与preload混用导致资源竞争。
懒加载本身不提升首屏速度，反而可能拖慢——如果用错时机或没做首屏保护。
loading="lazy"会阻塞首屏渲染吗
不会直接阻塞，但会干扰关键资源调度。浏览器看到 loading="lazy" 的 <img> 时，会推迟请求，哪怕它就在首屏内（比如被 margin-top: -100px 拉上来的 banner 图）。Chrome 会按“视口预测”逻辑加载，但预测不准就导致首屏图延迟出现。
- 首屏图片必须显式设
loading="eager"或干脆不加该属性 - 所有带
loading="lazy"的<img>应确保其offsetTop明显大于视口高度（可用 DevTools 的 “Rendering > Paint flashing” 验证） - 若用 CSS
background-image实现首屏图，loading属性完全无效，必须靠内联 CSS 或 preload 补救
IntersectionObserver 初始化太晚导致首屏空白
常见错误是把懒加载监听器塞进 DOMContentLoaded 或 window.onload 里。此时 DOM 已就绪、样式已计算、甚至首屏内容都渲染完了，用户已经看到占位符或白块。
- 正确时机是
document.readyState === 'interactive'，此时 HTML 解析完成，DOM 可访问，但样式/脚本尚未全部加载 - 推荐在
内联一段小脚本，立即初始化IntersectionObserver，并传入rootMargin: '0px 0px 300px 0px'提前触发 - 避免在 React/Vue 组件的
mounted或useEffect中注册 observer——路由跳转后这些钩子才执行，首屏已过
preload 和 lazy 加载混用时的资源竞争
<link rel="preload"> 和 loading="lazy" 同时作用于同一张图，浏览器行为不一致：Chrome 会优先走 preload，Safari 可能忽略或报 warning，Edge 有时两者都发请求造成重复。
- preload 只用于明确「当前导航必用」的资源，例如首屏 Hero 图的
src地址，且必须配as="image"和正确crossorigin - 非首屏图不要 preload；若用了，务必移除对应
loading="lazy"，否则语义冲突 - 验证方式：打开 Chrome DevTools → Network 面板，看请求 Priority —— preload 应为 high，lazy 图应为 low 或未出现在首屏请求流中
最易被忽略的是：懒加载不是开关，而是调度策略。它必须配合首屏资源识别、加载优先级声明、以及降级兜底（比如 Safari 不支持 loading="lazy" 时，JS 方案是否真能接管），缺一环，首屏就掉帧。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
