For sites with a large number of DOM elements, do IFrame have some performance advantages to present some content ? For example, in which I am working on, there is a very large HTML-based tree in which thousands nodes can be included at one time (although not all have been filled once). Keeping this shape aside from disposable problems, would it be of no use to keep this content in an iframe compared to the main content? Do browsers operate differently for embedded content within the IFrame? Will this content be improved by jquery selector performance? I am more interested in how this applies to IE 7, although I would be curious if it is different between browsers.
+1 For a good question, I have no difference in dealing with memory between frame and non-frame based content; I have written some xhml parser and memory memory; Nodes should be kept in memory regardless of where they are stored. All id is done by lookup keys (hashtable), so the archive can be quite big with a non-linear effect.
This is the parsing and memory side; However, I've found that the rendering time includes large internal HTML, so try using the document.createElement pattern instead (if applicable). I have experienced this behavior in various browsers including IE7.
Where DOM elements are also generated, are all nodes server-side supplied, or do you send JSON to the customer and make trees in Javascript? I can confirm that properly created Javascript object tree can handle thousands of nodes very efficiently, so if your rendering scheme is client-based and all nodes are not displayed once, then the actual dom will be very low.
The actual decision point will be round tripping. If you want to make a complex page as much as possible, it may prove sufficient justification to break it into the frame so that it does not need to be repeated to all the contents.
Comments
Post a Comment