iframe 会阻塞 window.onload，必须通过 data-src + IntersectionObserver 延迟加载；每个 iframe 独占渲染进程，显著增加内存占用；未加 sandbox 极不安全，SEO 和可访问性极差，核心内容不应仅存于 iframe 中。
iframe 会阻塞 window.onload，别指望首屏快
只要 HTML 里写了 <iframe src="...">，浏览器就必须等它连同所有子资源（JS、CSS、图片、字体）全部加载执行完，才触发主页面的 window.onload。哪怕 iframe 指向的是个空页面，这个阻塞也真实存在。实测中，一个加载缓慢的 iframe 可让整个页面右上角转圈持续 5 秒以上，document.readyState 卡在 interactive 状态不动。
真正有效的解法不是“优化 iframe 内容”，而是让它不参与初始渲染：
- 初始 HTML 中彻底删掉
src，改用data-src存地址 - 用
IntersectionObserver监听进入视口再赋值iframe.src，并立即unobserve() - 首屏必需？那就用
loading="eager"显式声明，而不是靠默认行为赌运气 - 老浏览器（如 IE）不支持
loading属性，会被忽略，回退成 eager 行为——这点必须写进兼容性 checklist
每个 iframe 都是独立渲染进程，内存翻倍不是夸张
Chromium 架构下，每个 iframe 默认启动一个独立的渲染进程（或至少独占 JSHeap 和 Document 实例）。DevTools 的 Memory 面板里，你能清晰看到多个 Document 条目和对应的 JS 堆增长。3 个 iframe 常使内存占用比纯单页高 30%~50%，低端 Android 设备极易因内存压力触发 iframe 卸载或白屏。
这不是理论瓶颈，而是可测量的硬约束：
立即学习“前端免费学习笔记（深入）”；
- 避免在 Tab 切换组件里反复创建/销毁 iframe——DOM 复用 +
display: none比重建轻量得多 - 禁用 iframe 内部的
console.log和未清理的定时器，它们会长期驻留 JS 堆 - 若 iframe 内是 React/Vue 应用，确保其
unmount逻辑被正确调用，否则 DOM 节点和事件监听器可能泄漏 - 不要用 iframe 加载同一套 UI 组件库（比如把 Header 用 iframe 嵌入三次），CSS 和 JS 会重复下载执行
sandbox 不是可选项，是安全底线
不加 sandbox 的 iframe，等于把完整网页执行权限白送给第三方：它能运行脚本、提交表单、弹窗、访问 localStorage（同源时），甚至尝试 top.location.href 跳转劫持。金融类应用曾因此出现过支付页被 iframe 内恶意脚本重定向的事故。
最小可用配置必须显式声明：
-
sandbox="allow-scripts"—— 允许执行 JS，但禁用 DOM 访问、表单提交、弹窗等 - 需要跨域通信？只加
allow-same-origin，且必须配合postMessage使用，绝不能仅靠它开权限 -
sandbox=""（空值）最严格：连脚本都不允许运行，适合仅展示 PDF 或静态 HTML - 千万别写
sandbox="allow-top-navigation"—— 这等于授权 iframe 控制整个浏览器窗口
SEO 和可访问性在 iframe 里基本归零
Google 官方明确：搜索引擎不会执行 iframe 内的 JS，也不会索引其 HTML 内容（除非该 URL 被单独抓取）。屏幕阅读器对 iframe 的支持极弱，尤其缺少 title 或 aria-label 时，用户完全不知道里面是什么。
如果业务逻辑依赖 iframe 内容（比如商品详情、表单字段），补救措施不是“尽量优化”，而是重构：
-
title属性不可省，例如<iframe title="用户收货地址表单"> - 提供
<noscript>或<div>备用文案，且语义必须与 iframe 内容一致 - 核心业务内容（如文章正文、下单按钮）绝不能只存在于 iframe 中
- 考虑用 Web Components 替代：自定义元素可复用、可 SEO、可无障碍，且无 iframe 隔离开销
复杂单页应用里，iframe 不是“组件化”的捷径，而是性能、安全、可维护性的放大器——它把小问题变成大故障，把边界条件变成必现 bug。真正要做的，不是调优 iframe，而是判断：这件事，非得用 iframe 吗？
