对于具有大量DOM元素的网站，在iframe中呈现某些内容是否有任何性能优势？例如，我正在处理的应用程序有一个非常大的基于html的树，一次可能包含数以万计的节点（尽管一次不能加载）。抛开这种大小的树可用性问题，将这些内容放在iframe中，而不是在主页面中会有什么好处？浏览器对内嵌在iframe中的内容处理内存不同吗？这会通过隔离此内容来提高jquery选择器的性能吗？我最感兴趣的是如何应用于IE 7，尽管如果浏览器不同，我会好奇的。iframe是否可以提高具有大量dom元素的网站的性能？
+1对于一个好问题。我不知道帧和基于非帧的内容之间的内存处理有什么区别;我写了几个XHTML解析器，内存就是内存;无论节点在哪里存储，节点都会占用内存。所有的ID查找都是通过键（哈希表）完成的，所以这些集合可以非常大并且具有非线性影响。
这是解析和内存方面;不过，我发现渲染时间可能会因较大的innerHTML插入而受到影响，所以请尝试使用document.createElement模式（如果适用）。我在各种浏览器中体验过这种行为，包括IE7。
DOM元素的起源也很重要。所有的节点都是服务器端提供的，还是将JSON发送给客户端并在JavaScript中创建树？我可以确认正确构建的JavaScript对象树可以非常有效地处理数千个节点，因此如果您的渲染方案是基于客户端的，并且所有节点都不会一次显示，那么实际的DOM将会更小。
真正的决策点将是往返。如果你一遍又一遍地重建一个复杂的页面，那么这可能是足够的理由将其分解为框架，以便所有的内容不需要一次又一次地通过电线发送。
错误，根本不是这样，使用Ajax并用您检索的HTML片段替换给定元素的内容。或者甚至更好，使用Ajax来获取JSON并用它构建HTML。 – Domenic 2010-09-25 21:17:37
@Domenic - 同意了，请参阅我对JSON和相关效率的评论。我关于框架的观点是，如果所有的HTML都是在服务器端生成的，并且无法更改模型，那么框架集或iframe可能会更快。 – 2010-09-25 21:38:34
“可能”是关键 - 尽管如此，这就是为什么我在我对原帖的评论中推荐测试的原因。看起来非常具体的实现是否使用iframe页面加载工具或Ajax + DOM插入最终会更快。也可能有挂钟或主观经验问题。 – Domenic 2010-09-26 17:46:17
为什么不自己运行一些测试？这似乎很可能对您的应用程序非常具体。 – Domenic 2010-09-25 18:57:42