Wednesday, October 18th, 2006

Benchmark: DOM vs. innerHTML

Category: JavaScript, Performance

Gleb Lebedev has gotten into the fun benchmark game. He created a benchmark of DOM vs. innerHTML testing on FF 1.5, IE 6, and Opera 9.

His example was building the Google page entirely using the DOM or innerHTML as seen in code here.

The results show that innerHTML is king for all browsers:

Benchmark of innertHTML and DOM

Posted by Dion Almaer at 8:42 am

3.5 rating from 43 votes


Comments feed TrackBack URI

This should shut up all the standard compliant nazis around here ;)

Comment by bartb — October 18, 2006

this is definitely a biased benchmark. any decent programmer could tell by just looking at both codes in 5 seconds…

Comment by Allan R. — October 18, 2006

Doing the test on my 2GHz MacBook on Safari I get
Result: innerHTML=’…’ = 2094
Result: document.createElement(‘… = 200.9950248756219

so would appear to hold for Safari as well as Opera, Firefox and IE

Comment by Geoff — October 18, 2006

Those who deny the speed of innerHTML aren’t based in reality

Comment by Mario — October 18, 2006

This benchmark isn’t even remotely valid. The biggest slowdown on the DOM creation here, by far, is all the createElement’s. Remove most of these by cloning instead and you’ll get a large speed increase. Fast enough to beat innerHTML? I dunno, but on a large enough DOM, or with enough DOM changes, I wouldn’t doubt it.

Comment by Mark Kahn — October 18, 2006

I would take this with a grain of salt. Just a quick scan shows me that this person missed at least one piece of html in their javascript dom creation:
function qs(el)

I would guess that there may be others…

Comment by Anon — October 18, 2006

Please don’t tell me that this compares …

The difference between finding a node, creating an element (defining it and it’s content), attaching it as a child to the aforementioned node and recursively continuing in that fashion.


inserting a chunk of nodes into a single element.

Because that would truly be a pointless benchmark!!!??

Comment by VoR — October 18, 2006

Hi, all!

Really the test was not about DOM vs. innerHTML, so it is valid. I think DOM can be optimized, but whole idea of this benchmark was to measure javascript+dhtml performance, not dhtml technique performance ;-)

So, Mario, you think cloning will be much faster? Can you give me a sample how I can use it on my JavaScript?

Comment by Gleb — October 18, 2006

I wouldn’t consider this to be a valid comparison, given innerHTML modifies the DOM once with a large string, whereas using createNode() and so on, 95 nodes are made; of course the “standard” method will be slower with that approach! :) .. Were one cloneNode() and one append to be used, I would expect you’d see similar results. When the browser has to individually create 95 nodes as with this “test”, there should be no question as to which method will be faster.

Secondly, I’m of the opinion that it is poor practice to be creating mass amounts of markup using Javascript. Instead, one should use a “templating” approach – have your HTML where it should belong to begin with (in the document as HTML), clone it once and append to a target once (or clone many times to a document fragment, and append that fragment once) as opposed to creating it all in Javascript.

With the new Yahoo! Photos, the cloning approach was taken to creating mass amounts of photo items using Javascript, and it has worked quite well. It is slightly slower than innerHTMLing a super-large string out, but I’ve found the standard DOM-based approach is easier to work with and maintain. If you don’t do multiple (or many) writes to the DOM (ideally just one like innerHTML), your performance should be quite comparable.

Comment by Scott Schiller — October 18, 2006

The only time I use innerHTML is to pull the data inside an element, that way I don’t have to deal with FF’s textNodes.

Comment by Andrew Herron — October 18, 2006

I agree with VoR in that this is often more about ease of use than it is about speed. To me, having direct references to specific DOM nodes is often a necessity. I’d be interested in seeing this same benchmark, but with this instead:

x.innerHTML = ‘….’;
var node1 = document.getElementById(‘node1’);
var node2 = document.getElementById(‘node2’);

so that you can get actual references to all the nodes you just created.

Granted, you often don’t NEED references to every single node, but the code isn’t doing the same thing otherwise!

Comment by Mark Kahn — October 18, 2006

It seems to me that both methods have there advantages and disadvantages. I took it for granted that the innerHTML option would be a lot faster (to write as well, in some cases), however DOM offers more structured control of individual elements. I don’t really see what all the fuss is about.

Comment by Richard Kimber — October 18, 2006

Using latest nightly Mozilla Firefox builds Im getting numbers like:
test1: 133
test2: 129

So next gen Firefox will be much faster than todays

Comment by Henrik Gemal — October 18, 2006

Why is he adding all those custom node attributes called “controlContainer”?

They are not part of any spec, the browser doesn’t need them, and they can only be slowing down the generation of his DOM creation.

Comment by Patrick Corcoran — October 18, 2006

Not all DOM selection techniques are created equal. Here’s a LIVE benchmark that you can run yourself to see how the various Javascript frameworks handle it.


Comment by Isaiah — October 18, 2006

Speed is usually not the critical factor for code– at least 90 – 95% of it– so I can’t see how you can make architectural decisions solely on this benchmark, whether it’s valid or not.

If I’m reading it right, the slowest code only takes 1/60th of a second, and has no affect on my server, where the bottlenecks usually are.

You can argue that this is a very simple page, and real pages are more complicated. In reality, though, the page complexity is bounded by what a user can comprehend, so it’s not going to be more than an order of magnitude more complicated. So for the most complicated reasonable page, we’re talking 1/6th of a second vs. 1/20th of a second (FF), and less of a difference on IE. These both seem within the realm of a “responsive” app.

Comment by ndp — October 18, 2006

It looks like Adblock Plus makes the test results much worse:
FIREFOX – NO Adblock
. Inner HTML: 512 514 516 513
. document.createElement: 169 164 165 164
FIREFOX – Adblock Plus disabled in interface
. Inner HTML: 204 207 204 207
. document.createElement: 117 115 117 115
FIREFOX – Adblock Plus Enabled
. Inner HTML: 171 166 165 155
. document.createElement: 111 118 113 105
OPERA 9.0 beta
. Inner HTML: 2800 2580 2635 2549
. document.createElement: 240 229 184 232
IE 6
. Inner HTML: 317 269 247 227
. document.createElement: 98 80 72 68

Does it mean JavaScript executes 3 times slower with Adblock Plus installed on Firefox? Or maybe only certain operations?

Comment by Abe Pazos — October 18, 2006

The simplification and convenience of innerHTML just can’t be beat. If you’re inserting content that fits a very rigid structure, you may not need it, but if you’re creating functions with a wide degree of flexibility, manual DOM methods can be hell.
You create a method that displays a confirmation message. Then you realize that you need to be able to display messages that occupy multiple paragraphs. Hmmm… Or even just throw in simple stuff like the need to include inline tags (em, strong, etc.).
Sure, you can create a parsing system of your own, but there’s no way you can possibly create one better than the compiled one built in to the browser and certainly nothing that can be implemented as easily as foo.innerHTML=bar.

Comment by Chuck — October 18, 2006

Is there really much point to this? Unless you’re doing some incredibly unusual dynamic building of pages, you’re typically just inserting a handful of elements in response to an event and *either* approach is going to be fast enough.

Comment by Steve — October 18, 2006

This code is based on my HTML2DOM converter used to create DHTML forms. So controlContainer is legacy :)

Comment by Gleb — October 19, 2006

Updated values from my benchmark:


Result: node.innerHtml=… 397.0 404.0 406.0 255.9 413.0
Result: document.createElement(‘… = 114.0 120.0 119.0 124.6 151.0
Result: document.cloneNode(‘… = 122.0 115.0 120.0 122.3 150.0

IE 32 + AOL Toolbar

Result: node.innerHtml=… 101.0 89.0 85.0 95.0 90.0
Result: document.createElement(‘… = 30.5 30.0 29.5 29.0 28.0
Result: document.cloneNode(‘… = 40.0 38.4 38.0 36.0 35.0

IE 64

Result: node.innerHtml=… 160.0 147.0 118.0 90.0 57.1
Result: document.createElement(‘… = 34.4 32.0 29.6 35.0 40.4
Result: document.cloneNode(‘… = 37.4 36.4 35.0 32.5 29.0


Result: node.innerHtml=… 1901.0 941.0 1300.3 9.0 1919.0
Result: document.createElement(‘… = 320.0 327.8 330.7 336.0 331.0
Result: document.cloneNode(‘… = 344.0 348.0 360.0 347.0 350.0

Opera is still the fastest, but there is no big diffenece between createElement and cloneNode…

Comment by Gleb — October 19, 2006

About my post above, I asked Wladimir Palant, (main) author of Adblock Plus about the JavaScript performance and he told me this specific test creates lots of images, which Adblock Plus must check to see if they are ads or not, making it slower. It should not happen with typical JavaScript code.

Comment by Abe Pazos — October 19, 2006

Totally agree with Richard Kimber. In practice, I have always used document.createDocumentFragment() to ameliorate the performance problems with complex DOM manipulation. At times though I have used innerHTML because its so simple (Chuck) but I always feel a little bit dirty for doing so – like fast food dinners.

Comment by Luis Ortiz — October 19, 2006


kmpkkruy wzngfdy qypnplfqru

Trackback by fdwflezcsk — October 25, 2006

After searching for many hours on trying to find a way to dynamically populate an enormous drop down list (up to 14k items). Nothing beats innerHTML. We’re talking dollars and cents here. It’s not rocket science. If innerHTML works in a fraction of a second and the DOM method takes 4 seconds, just do the math. The client makes $x per minute. and if they lose 3.5 seconds per user per list change, they’re not going to care how it’s coded, they’ll want innerHTML. Welcome to the real world. I just want an easier way to pop it into my elements where IE won’t try to parse it. Any ideas?

Comment by David Friedland — October 30, 2006

[…] DOM vs. innerHTML Published October 19th, 2006 Enter the Matrix 출처: Ajaxian and code here […]

Pingback by DOM vs. innerHTML « 웃으며 사는 세상 — November 30, 2006

This test is a complete nonsense. why dont you guys append those DIV elements to the document and see which one is really faster. Speaking from experience, IE will be the clear winner if you appendChild right after createElement method. There is no browser out there which can beat Internet Explorer if you really know what you are doing.

Comment by domguru — May 19, 2007

Leave a comment

You must be logged in to post a comment.