14

What are the best practices for doing DOM insertion?

  • Is it faster to insert large chunks of html vs element at a time in a loop?
  • Does it matter what html you are inserting, or only how big the chunk is?
  • It it faster to insert a table, vs inserting just the rows using the table hack?
ajreal
  • 44,929
  • 10
  • 81
  • 118
mkoryak
  • 54,015
  • 59
  • 193
  • 252
  • I uploaded a script for reasonably efficient table updates: http://mercurial.intuxication.org/hg/js-hacks/raw-file/tip/updatetable.js ; the table to be updated must have a `tbody` element; using `innerHTML` might still be faster, though – Christoph Mar 11 '09 at 19:30
  • interesting. i cant use your script because i return premade html. ill keep this in mind though if i ever need something like this. also, what are there js-hacks? i am looking at them all now =) – mkoryak Mar 11 '09 at 20:20
  • @mkoryak, regarding js-hacks: 2 months ago, I began dumping the standalone-scripts I had lying around to a mercurial repository; some of these are quite useful (especially capture.js), but most are just-for-fun... – Christoph Mar 11 '09 at 21:55

5 Answers5

18

Setting innerHTML is often faster than inserting seperate nodes.

Another possibility would be to create a DocumentFragment, which allows to insert the nodes all at once. Another advantage of using DocumentFragments is that they can easily be cloned, which can replace a lot of use cases for innerHTML and is potentially faster as no parsing is involved.

Christoph
  • 149,808
  • 36
  • 172
  • 230
  • Upvoted for DocumentFragment. It's not quite as fast as innerHTML across the board, but can be faster in real world cases (assuming lots of concat), and is generally a lot cleaner/better code. – eyelidlessness Mar 12 '09 at 03:59
11

innerHTML insertion is marginally faster than DOM manipulation 1:1 and gains more for cases where you're actually inserting multiple nodes and attributes etc.., but it's more error prone and dangerous given it's essentially an eval statement in disguise.

In my experience JS is so fast these days that the speed gains of innerHTML do not justify the risks for anything but the largest of insertions/iteration batches.

Long story short, you want to do the fewest DOM manipulations possible, so one tip when creating a hierarchy for insertion is to create them against each other in memory and then insert the highest element into the DOM at the last possible moment. That leaves the fewest render updates for the browser. Course again we're talking fractions of milliseconds...

annakata
  • 70,224
  • 16
  • 111
  • 179
  • i am inserting a 500kb block of rows. and its taking about 750ms which is notacable – mkoryak Mar 11 '09 at 15:28
  • 500k! A). this doesn't sound like JS is the right tool for the job B). you can't packet this into page chunks? C). unroll the loop as much as you can and go with innerHTML, that'll give you your lower boundary – annakata Mar 11 '09 at 15:51
  • 2
    interestingly, for removing nodes, `innerHTML` is much slower - http://jsperf.com/empty-an-element/4 – vsync Oct 07 '14 at 13:34
  • innerHTML insertion is marginally faster than DOM manipulation: This is simply not correct – Yair Levy Jul 09 '19 at 11:12
3

innerHTML is actually slower then direct DOM manipulation in many cases. check out this benchmark on jsperf

There is no "right answer", you will have to find the proper, most efficient method for your specific use case

Yair Levy
  • 669
  • 8
  • 9
1

For large chunks of html, it is definitely faster to assign the text to innerHTML. Though it is supported by all the major browser, innerHTML is not in the w3c standard, so some programmer hesitate to use it.

Maurice Perry
  • 31,563
  • 8
  • 67
  • 95
1

It's definitely faster to do it all at once. Also check out Steve Souder's blog and his book.

Hank Gay
  • 65,372
  • 31
  • 148
  • 218