The need for speed: innerHTML versus DOM manipulation

3 July 2007 · Estimated reading time: 4 minutes

At work, I’ve been tackling some fairly sophisticated JavaScript DOM manipulation scenarios. As such, I’ve started to run up against the limitations of my long-used technique of stuffing loads of HTML as a string into some element’s innerHTML property. Specifically, when inserting very long strings containing complex HTML, there can be a troublesome delay between when JavaScript thinks it’s done inserting the elements and when the elements are actually available for further manipulation.

After reading some articles on the subject, I conducted my own tests (go there to see some code!) of the speed of innerHTML versus direct DOM manipulation (in the process coming up with highly optimized versions of each.) I came to the conclusion that there is a bit of mythology on the Intertubes that may be based on incomplete knowledge of how DOM methods work.

Myth:

innerHTML execution is way faster than DOM scripting.

Truth:

When written optimally, DOM scripting ranges from clearly slower (run in Internet Explorer 6 and 7) to nearly as fast (on Gecko-based browsers) to slightly faster (on Safari and Opera). This also only takes into account the time it takes the browser to release the thread, not how long it takes for the new node(s) to be available for manipulation. Saying “[innerHTML] is faster than DOM. This is a proven fact.” is simply bogus.

Myth:

innerHTML is way easier to code up.

Truth:

There is some truth to this. For a novice scripter, if you have haven’t dealt much with XML or the DOM, it can be confusing to do more than just dump strings into innerHTML. But there are advantages to going the hard road. A big one (for me) is that innerHTML is not technically a standard so it offends my inner purist support for it could dwindle over time. More objectively, it does take time to attach nodes to the DOM when using innerHTML whereas nodes attached directly are available immediately. While not a problem in a lot of use cases, it’s cropped up as a problem for me in certain situations.

Myth:

innerHTML takes way less code to do the same thing.

Truth:

innerHTML takes way less code to do the same thing. So what? If innerHTML is causing problems that DOM scripting can solve, are you really so lazy that you’re going to avoid it anyway? I mean, isn’t that why it’s called work?

To be fair, there are some gotchas that are worth noting with DOM scripting. Namely, you can’t use HTML entities in text nodes (makes sense, but I learned the hard way). Instead, you have to use Unicode encoded entities. For example, rather than using ’ for an apostrophe, you have to use \u2019. Luckily, there are sites on the Interweb that let you look this stuff up.

The rest (at least in terms of optimizations) is common sense to most programmers, e.g., do as much work outside your loops as possible. One tip that I found really sped things up was to work on a document fragment, rather than directly manipulating the top level document object.

Conclusion

Any anthropologist will tell you that myths don’t have to be true to be useful. Maybe it’s better that JavaScript programmers don’t go the DOM route if they don’t fully understand how to make it work effectively. My advice? Bite the bullet and learn how to (efficiently) script the DOM.

Update: I should probably have been more explicit about this above, but you can get to the code I used to run my speed tests here.

Update 2009-12-25: After some discussion on the iUI Google Group, I updated my speed test to use PPK’s method for measuring DOM attachments. My conclusions above are unchanged.