loading属性仅是懒加载开关，真正影响性能的是是否满足生效前提及与其他机制配合；首屏关键图须显式设loading="eager"并配preload，lazy失效常见于缺宽高、transform容器、js动态插入等场景。
loading 属性本身不优化性能，它只是触发浏览器原生懒加载的开关；真正影响性能的是你是否满足它的生效前提，以及是否和其它机制（如 srcset、decoding、preload）配合得当。
哪些图片必须显式写 loading="eager"
首屏关键图不加这个属性，Safari（尤其是 iOS 16.3 及更早）可能直接跳过加载，出现白屏或图标缺失。这类图包括：
- Banner 主图、网站 Logo、用户头像、核心操作按钮图标
- 必须同时配
<link rel="preload" as="image" href="xxx">，且href和<img src>完全一致 - 禁止对
loading="lazy"的图再preload——逻辑冲突，会触发重复请求
loading="lazy" 失效的硬性条件
写了属性但图片仍全量加载，大概率是以下任一条件被触发：
-
<img>缺少width和height（内联或 CSS 均可），浏览器无法推断尺寸，部分 Safari 直接降级为eager - 父容器用了
transform、will-change: transform或overflow: hidden，破坏滚动根检测 - 图片是 JS 动态插入的（如 React
map()、Vuev-for渲染），不属于初始 HTML - 错把
loading="lazy"写在<source></source>上——该属性只对<img>有效 - 图片位于
<table> 内部（<code><td> 或 <code><tr> 中），Chrome 对表格子元素支持极弱 <h3>让 <code>loading="lazy"真正生效的最小必要条件不是加了就完事，得满足浏览器的“信任前提”：
- 图片必须在初始 HTML 中存在（SSR 渲染后已输出），且默认不在首屏内（
getBoundingClientRect().top > window.innerHeight） - 确保宽高可推断：用内联
width/height，或 CSSaspect-ratio+width: 100%防止布局偏移（CLS） - 避免脱离文档流：不用
position: absolute或fixed占位（哪怕top: -9999px），浏览器可能判定为“已渲染但不可见”，跳过懒加载检查 - 移动端必须声明
<meta name="viewport">，否则 WebView 可能忽略该属性或降级处理
什么时候该放弃
loading="lazy"，改用IntersectionObserver原生
lazy是声明式、零成本的基线优化，但控制粒度有限：- 需要提前加载（如离视口还有 200px 就触发）——
loading="lazy"没有rootMargin配置项 - 需要加载失败 fallback、LQIP 占位、解码控制或自定义 loading 状态
- 图片被包裹在
transform容器中，又无法改样式时，IntersectionObserver是唯一可靠路径 - 注意：不要给已设
loading="lazy"的<img>再套 JS 懒加载——会导致竞态和重复请求
最常被忽略的一点：
loading="lazy"的行为依赖浏览器内部预判（比如 Chrome 默认提前约 1250px 加载），它不是“滚动到才发请求”，而是“布局后批量检查+预取”。如果你没看到 Network 面板里图片请求明显滞后，先检查宽高和容器样式，而不是怀疑属性写错了。 - 图片必须在初始 HTML 中存在（SSR 渲染后已输出），且默认不在首屏内（
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
