loading="lazy"仅对初始HTML中不在首屏、有width/height、父容器无transform/overflow:hidden的<img>生效;否则静默退化为立即加载甚至白屏。

loading="lazy" 能用,但不是写了就生效——它只对初始 HTML 中存在、不在首屏、有明确 width 和 height、父容器没 transform 或 overflow: hidden 的 <img> 生效;其他情况浏览器会静默退化为立即加载,甚至白屏。
哪些图片必须写 loading="eager"
首屏关键图不加 loading="eager",Safari(尤其 iOS 16.3 及更早)可能跳过加载,直接白屏。这类图包括:
- Banner 主图、网站 Logo、用户头像、核心按钮图标
- 所有在
<head>中已<link rel="preload" as="image">的图,href必须和<img src>完全一致 - 不能和
decoding="async"共用——首屏图解码异步会拖慢 LCP
loading="lazy" 失效的硬性条件
写了属性却全量加载,大概率踩中以下任一限制:
-
<img>缺少width和height属性(CSS 设置宽高不算数,Safari 15.4+ 直接拒懒加载) - 父容器用了
transform、will-change: transform或overflow: hidden,破坏滚动根检测 - 图片是 JS 动态插入(如 React
map()、Vuev-for渲染),不属于初始 HTML - 把
loading="lazy"错写在<source>上——该属性只对最外层<img>有效 - 图片在
<table>内部(Chrome 对表格子元素懒加载支持极弱)
和 srcset / sizes 配合时容易踩的坑
单独加 loading="lazy" 不解决响应式图片带宽浪费问题。懒加载触发时浏览器才选图,没配 sizes 就只能拉 src 里的 fallback 图——大概率是桌面大图,移动端白耗流量。
立即学习“前端免费学习笔记(深入)”;
-
srcset必须用w单位标注源图固有宽度:cat-400w.webp 400w, cat-800w.webp 800w -
sizes要反映真实布局宽度,比如:sizes="(max-width: 480px) 100vw, (max-width: 1024px) 50vw, 800px" -
src仅作降级兜底,必须指向小尺寸图(如cat-400w.webp),不能留空或指向大图 - 禁止给
loading="lazy"的图再preload——逻辑冲突,触发重复请求
验证是否真正生效,别只看 Network 面板
两个真正起作用的信号:
- DevTools → Network → 勾选
Disable cache,刷新后滚动,观察图片请求是否明显滞后于页面加载完成时间 - Elements 面板中右键图片节点 →
Break on attribute modifications,滚动时若看到src被浏览器动态设置,说明原生 lazy 在接管 - Lighthouse 的「Offscreen images」建议消失 ≠ 懒加载生效,它只检查属性是否存在,不校验行为
真正要注意的是:iOS 14 及以下 Safari 完全不识别 loading 属性,微信旧版 X5 WebView 同样忽略;服务端模板若过滤自定义属性,这个值根本不会出现在最终 HTML 中。



















