你有没有试过在自己的ref="/tag/88/" style="color:#B2A89E;font-weight:bold;">网页里嵌个 YouTube 视频，或者加个第三方评论框，结果页面加载突然变卡？很多人第一反应是：是不是 iframe 搞的鬼？
iframe 本身不慢，但它的行为很“实在”
iframe 就像给网页开了个独立小窗口，它会单独发起 HTTP 请求、下载资源、解析 HTML、执行 JS、渲染样式——整个流程和主页面几乎一样。也就是说，一个 iframe 不是“轻量级插件”，而是一个迷你浏览器环境。
举个例子：你在博客文章末尾加了这样一段代码：
<iframe src="https://example-widget.com/loader.js" width="300" height="200"></iframe>看起来只是嵌个小模块，但如果这个域名响应慢、JS 文件大、还带一堆广告追踪脚本，那你的整页首屏时间（FCP）和可交互时间（TTI）就可能被它悄悄拉长。
这些情况最容易“中招”
● 第三方 iframe 加载失败或超时，浏览器默认会等它几秒才放弃，期间主线程可能被阻塞；
● 多个 iframe 同时加载（比如一页嵌了 3 个社交媒体分享按钮 + 1 个客服浮窗），DNS 查询、TCP 连接、SSL 握手全得重复来一遍；
● iframe 里的页面自己又嵌 iframe（俗称“iframe 套娃”），层级一深，内存占用和重排重绘压力直线上升。
怎么判断是不是 iframe 拖累了你？
打开 Chrome 开发者工具 → Network 标签页 → 刷新页面 → 看看有没有标着 iframe 的请求长时间黄条（等待中）或红条（失败）。再切到 Performance 标签页录一段加载过程，放大看主线程活动，如果某段空白期后突然冒出大量 JS 执行和布局计算，十有八九是 iframe 里的脚本在发力。
能优化吗？当然可以
懒加载是个实用办法：用 loading="lazy" 属性（现代浏览器已支持）让非首屏 iframe 推迟到滚动进入视口再加载：
<iframe src="https://widget.example.com/" loading="lazy" width="400" height="300"></iframe>更进一步，可以用 Intersection Observer 手动控制加载时机，甚至先放个占位图，点击再唤起 iframe，既保体验又省资源。
另外，别忽略 sandbox 属性。哪怕只是加个 sandbox="allow-scripts"，也能限制 iframe 内脚本的权限，减少潜在的性能干扰和安全风险。
说到底，iframe 不是洪水猛兽，但它确实不像 img 或 div 那么“听话”。用之前多问一句：这东西非嵌不可吗？能不能换 API 调用？能不能服务端直出？有时候删掉一个 iframe，FMP（最大内容绘制）直接快上 800ms。”