10

IE7/Windows XP

I have a third party component in my page that does a lot of DOM manipulation to adjust itself each time the browser window is resized.

Unfortunately I have little control of what it does internally and I have optimized everything else (such as callbacks and event handlers) as much as I can. I can't take the component off the flow by setting display:none because it fails measuring itself if I do so.

In general, does setting visibility of the container to invisible during the resize help improve DOM rendering performance?

Chetan S
  • 23,637
  • 2
  • 63
  • 78
  • What strager said. We don't know what you're doing, therefore it's pretty hard to say what'll help... – Shog9 Feb 13 '09 at 00:18
  • Ok... In general, who knows? I've seen it help once, and even then it only cut about 100ms off of a worst-case scenario where a given routine took several seconds to run. I ended up getting far better performance by simply measuring everything first and then manipulating it. – Shog9 Feb 13 '09 at 00:35
  • possibly related - https://stackoverflow.com/q/14058013/104380 – vsync Jun 18 '17 at 13:36

3 Answers3

11

Caveat: I have not specifically tested this with IE7, but I am reasonably confident based on what I know about its DOM manipulation model.

Changing CSS properties (whether display: none or visibility: hidden or what-have-you) will not affect the performance of DOM manipulation in any version of any browser I've worked with. The primary way to improve the speed of DOM manipulation is to remove the node(s) you will be working with from the document tree, performing your manipulations, and adding them back in. This involves keeping track of their succeeding sibling nodes, if any (for use with insertBefore), which can become complex if you're working with nodes which are scattered around the document.

One technique I have seen when performing a large number of DOM manipulations all at once is to get a list of the body element's children, remove them, perform your manipulations (wherever they fall in the document tree), and then reappend the body's child nodes. Depending on how long your DOM manipulations take (which is itself partially dependent on the speed of your visitor's computer!), this can produce a noticeable flicker. This is why sites manipulating content via AJAX will usually replace any temporarily-removed content with a "spinner" or loading screen.

Ben Blank
  • 54,908
  • 28
  • 127
  • 156
  • Thank you. In my case though, part of rendering operation involves measuring offsetHeight of a few elements (the third party component relies of it). So I think I'm out of luck. – Chetan S Feb 13 '09 at 00:54
  • Perhaps measure, remove, modify, reinsert? – Ben Blank Feb 13 '09 at 19:00
2

I'm not certain, but removing it from the active document's DOM then manipulating it does improve performance. After all manipulating is done, attach it back to the document's DOM. Think of it sort of like video buffer swapping.

Richard Levasseur
  • 14,562
  • 6
  • 50
  • 63
0

I've just tested this using a button-dialog situation I'm having. Basically, I copied one long dialog many times until I have a 10000-line file.

html:

<div class="no-visible dialog">
    ....
</div>

css:

.no-visible {
    visibility: hidden;
    animation:....
    ....
}

Conslusion:

It slowed down the computer a lot with all the JS and CSS, and all my css animations were gone. Especially when a button is clicked and JS have to find to corresponding dialog to display, it lagged.

Solution:

Put the dialogs in another html (dialogs.html) and load the necessory when needed.

Daniel Cheung
  • 4,779
  • 1
  • 30
  • 63