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:
3.6 rating from 37 votes
This should shut up all the standard compliant nazis around here ;)
this is definitely a biased benchmark. any decent programmer could tell by just looking at both codes in 5 seconds…
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
Those who deny the speed of innerHTML aren’t based in reality
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.
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…
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.
versus..
inserting a chunk of nodes into a single element.
Because that would truly be a pointless benchmark!!!??
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?
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.
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.
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′);
…etc
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!
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.
Using latest nightly Mozilla Firefox builds Im getting numbers like:
test1: 133
test2: 129
So next gen Firefox will be much faster than todays
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.
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.
http://wiki.mootools.net/benchmark
Isaiah
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.
It looks like Adblock Plus makes the test results much worse:
FIREFOX 1.5.0.7 - NO Adblock
. Inner HTML: 512 514 516 513
. document.createElement: 169 164 165 164
FIREFOX - Adblock Plus 0.7.1.2 disabled in interface
. Inner HTML: 204 207 204 207
. document.createElement: 117 115 117 115
FIREFOX - Adblock Plus 0.7.1.2 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?
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.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.
This code is based on my HTML2DOM converter used to create DHTML forms. So controlContainer is legacy :)
Updated values from my benchmark:
MOZ
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
Opera
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…
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.
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.
I guess the speed is very iportant but you never(!) shouldn’t forget about memory usage. Pls review my own tests and try to repeat yours with delta memory checking.
fwxrrjchu
kmpkkruy wzngfdy qypnplfqru
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?
[...] DOM vs. innerHTML Published October 19th, 2006 Enter the Matrix 출처: Ajaxian and code here [...]
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.