• 初阶:
      • 是什么:一种网页嵌套技术,它能够将其它页面,以独立 “浏览器上下文” 方式嵌入当前页面
        • 有自己的单独的 dom 树结构、cssom 结构、独立渲染上下文等完整的浏览器环境
        • 独立浏览器历史栈
        • 有严格隔离的 js、css 安全策略
      • 适用场景:
        • 过去:实现 ajax 请求、form 表单异步提交、SPA、长轮询效果
        • 现在:广告、微前端;其次,鉴于 iframe 简便与兼容性,有不少大网站依然提供了 iframe 嵌入功能,如 youtube、google map 等
    • 中阶:
      • 性能:
        • iframe 会阻塞父页面的 onload 事件,且 iframe dom 节点创建耗时很大,容易导致主页面(onloade)耗时增加
        • iframe 与父页面共享连接池,这意味着同域受请求并发限制影响,互相阻塞
        • iframe 需要完整走打开页面流程:dns、tls、资源请求、资源响应、dom 构建等,此时:
          • 如果资源的缓存策略没设置好,可能增加额外的http请求
          • 需要构建一颗独立的 dom、cssom 树等
        • 更甚的,不同站点的 iframe 运行在一个独立进程,iframe 与主页面之间的通讯基本都是IPC
        • 消耗更多的内存
      • 安全性:iframe 提供了一套严格的安全限制,包括:
        • 通过进程隔离,严格控制两端信息互通
        • 限制主页面与 iframe 之间互相调用接口,例如不能直接修改对方的 dom content
        • sandbox 限制了 iframe 能执行的操作类型,例如限制弹框
        • 通过 csp 限制可执行脚本来源
        • 通过 allow 限制 子页面 特性策略,例如不能调起摄像头等
        • X-Frames-Options 头限制页面可以作用子页面被嵌入哪些页面
      • 其它问题:
        • 丢失可导航性
        • iframe 内容无法被搜索引擎理解
    • 高阶:
      • 不同站点时,out of process iframe 模型:多进程渲染同一个页面,很多能力需要借助 browser 实现
        • 能复用操作系统,进程级别的资源隔离策略来确保安全性
        • iframe 与 主页面 各自有一个 renderer 进程,两者各自控制自己的渲染区域,最终通过 browser 进程合并渲染结果后渲染到屏幕上
        • 交互:browser 需要判断用户交互区域属于那个页面,之后将事件通过 ipc 方式传递给相应 renderer
        • 通讯:
          • iframe 与 主页面,互相持有对方的 window 代理对象, postmessage 或其它交互操作时,消息会先放到 browser 进程,之后再转发到具体进程
          • 同站点之间使用同一个进程,支持同步通讯;不同站点使用不同进程,需要ipc通讯
        • same-site vs same-origin
          • origin:域名、协议、端口
          • site:根域名 + 二级域名相同,认为是同站点
      • 感受:虽然很多文章说iframe不好,但实际上它却一直存活至今,在不同时期被用于解决不同问题,从最开始用于实现 spa,到实现异步数据请求,到现在的安全沙箱,未来 ShadowRealm API 正式发布后,不知道iframe会不会又被用于解决其它问题

    资料: