能省资源，但仅对非首屏、未进入视口的iframe生效；首屏iframe仍会eager加载，真正受益的是页脚客服、tab切换报表等滚动后内容。
loading="lazy" 在多 iframe 页面里真能省资源？
能，但收益取决于 iframe 的位置和加载时机。浏览器只对「非首屏、未进入视口」的 iframe 延迟发起请求，所以如果页面顶部堆了 5 个 iframe，哪怕加了 loading="lazy"，它们仍会 eager 加载——因为默认就在视口内。真正受益的是那些滚动后才出现的内容，比如页脚的客服弹窗、分页后的商品详情嵌入、tab 切换后才显示的报表模块。
常见误判点：
- 以为加了
loading="lazy"就万事大吉，没检查实际滚动行为是否触发加载 - 把首屏关键 iframe（如登录态校验用的隐藏 iframe）也设为 lazy，导致功能异常
- 在 SSR 渲染中直接输出
loading="lazy"，但服务端无法判断视口位置，纯靠客户端补救
Chrome 与 Safari 对 loading 属性的处理差异
Chrome 80+ 和 Edge 80+ 对 loading="lazy" 的实现最稳定，支持 IntersectionObserver 底层调度，且对 iframe 的懒加载触发阈值较宽松（进入视口前约 128px 就开始预取）。Safari 15.4+ 虽支持该属性，但存在两个硬伤：
- 不支持
iframe的loading="lazy"回退机制：若 iframe 已被 JS 动态插入并设置了src，再补上loading="lazy"无效 - 对
height为0或display: none的 iframe 完全忽略 lazy 行为，直接 eager 加载
Firefox 75+ 支持，但需注意其对 srcdoc + loading="lazy" 组合不生效——这种内联内容会被立即解析。
立即学习“前端免费学习笔记（深入）”；
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
loading="lazy" 和 IntersectionObserver 混用时的冲突点
不能同时依赖两者控制同一 iframe 的加载时机。典型冲突场景：
- HTML 中写了
<iframe src="a.html" loading="lazy"></iframe>，JS 又用IntersectionObserver监听并手动赋值src—— 浏览器可能先发一次 lazy 请求，等 JS 执行时又发一次，造成重复加载 - observer 触发后未清除监听，而 iframe 被复用（如 tab 切换），导致多次赋值
src，引发重复初始化或状态错乱 - 父容器使用
transform: translateZ(0)或will-change: transform，某些 Safari 版本会破坏 IntersectionObserver 的检测精度，使 lazy 加载失效
建议做法：要么纯用 loading="lazy"（适合静态布局），要么纯用 IntersectionObserver + data-src（适合动态/可复用场景），别混搭。
复杂页面中 iframe 加载收益的真实评估维度
单纯看「减少几个请求」意义不大，要结合 LCP、TTI、内存占用三方面看：
-
LCP（最大内容绘制）：首屏无 iframe 或仅含 skeleton 占位时提升明显；若首屏 iframe 是地图或视频预览，loading="lazy"反而拖慢 LCP（因延迟加载导致关键内容延后渲染） -
TTI（可交互时间）：多个 eager iframe 会抢占主线程解析和执行资源，启用 lazy 后 TTI 平均缩短 15%~30%，尤其在低端安卓机上效果显著 - 内存：每个 iframe 实例至少占用 2~5MB 内存，懒加载可让非活跃 tab 或折叠区域的 iframe 始终不创建 document 实例，实测 12 个 iframe 页面内存峰值下降 40%+
真正容易被忽略的是：lazy 加载不等于「不加载」，只是推迟。如果用户快速滚动到底部，所有 lazy iframe 会在短时间内集中触发，可能引发网络拥塞或服务端限流。这时候得配合节流策略或预加载提示，而不是只盯着属性本身。
