對於具有大量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