6 ms·

How Bad is DOM Interaction Really?

90 points by andyshora 13y ago

pcunite 13y ago
After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster ways. I'm use to threading database calls, using message queues, and views updating themselves from caches. It’s a new world for me and feels somewhat like a step backwards. Here I come html5!
- TheAceOfHearts 13y ago
  The only thing that matters in most cases is that it's being done over 60FPS. Use Chrome Dev Tools and to monitor the framerate.
- oscilloscope 13y ago
  You can use queues when creating a large number of elements. Use requestAnimationFrame and each frame pop some elements off the queue to render them. This will help prevent the page from locking up during render events.
  - PavlovsCat 13y ago
    Also, when adding many elements (or not so many, but over and over), add them to a DocumentFragment [ http://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment http://developer.mozilla.org/en-US/docs/Web/API/DocumentFrag... ] first, and then attach that to the DOM in one piece (one big DOM update is better than many small ones).
- hising 13y ago
  I guess knowledge like yours are important in making better tools and patterns available for JavaScript developers who haven't yet had the opportunity to work with those types of tools, patterns and languages you have. A big opportunity for people who come from more mature environments to share their knowledge!
- ivanca 13y ago
  For performance any platform is a step backwards, the leveling for easier/broader access is never free.
  - fuckjavascript 13y ago
    Rubbish. "Leveling" done in userspace (e.g. libraries) doesn't create a fundamental step back. The browser is just a horribly designed, and why, in spite of years of procrastination and denial - and HN is no exception - it has ultimately ended up as a virtual machine combined with basic primitives (albeit years too late and not done very well at all). My hellbanning on this site is a great example of why this site sucks. How many of the losers who hang out on this site all day collecting karma (as opposed to.. programming) called these problems? Practically nobody, and yet HN is deprived of my wisdom because I am too blunt and don't have an established account.
- tlarkworthy 13y ago
  try angular JS for self updating views.
- slacka 13y ago
  Avoiding writes to the DOM is a good tip for beginners. As a desktop developer, you're going to realize quickly that DOM is decent model for documents, but a terrible paradigm for interactive applications. Overall performance is terrible and varies widely between browsers. We either need a new standard or a DOM browser battle like what happened with JavaScript, bringing it from 100x to 3x of native.
bkjelden 13y ago
Caching jQuery selectors may result in a speedup, but as with all caching systems I've run into nasty, hard to trace bugs that were the result of stale cached jQuery selectors. So I'd add the caveat to caching jQuery selectors that standard premature optimization rules still apply.
- bdg 13y ago
  Caching them in local fucntion scope should be harmless. For instance: grabbing #x, using it inside a decision structure and iterator. Caching #x as a global constant is probably setting you up for some fun debuging later.
Semiapies 13y ago
These timings are all remarkably random, even with 10k repetitions.
- esailija 13y ago
  In both selector tests, the code calls `.html()` as well. It also uses a direct #id selector, I.E. does not "search the entire DOM" like it says.
malandrew 13y ago
No discussion of repaint and reflow? You can't leave a discussion of those out when talking about the cost of DOM manipulation. You absolutely can touch the DOM, but should do so through and interface that manages or eliminates repaint and reflow.
- ghostdiver 13y ago
  I have same feeling, Making single frame of JS code to run fast is cool and dandy, but eventually browser will have to make freeze and do reflow+repaint. Eventually it will make profiling harder, think about caching .offsetHeight etc. properties. It does decrease script execution time, but it does not make your app to work faster.
  - jcampbell1 13y ago
    The important trick to know is, don't mix DOM modification with DOM measurement. Measuring the DOM is what triggers the DOM modification queue to get flushed. if you do something like $('a').each(function(k,e){ $(e).append('<span>' ...); var width = $(e).width() // do something with the width; } If you have code like the above, it is going to cause a repaint on each iteration. If you unroll it into three separate loops, one that does dom modification, one that does dom measurement, and another that does modification, then you will drop the number of repaints from potentially 100s to just 2.
    - ghostdiver 13y ago
      It does not trigger repaint on each iteration.
ender7 13y ago
The real hits to performance do not come from "I did X writes" or "I did Y reads", but rather from situations such as "I did X writes interleaved with Y reads, which caused Z reflows". Or "I needed to update a tiny part of the screen but triggered a full-page repaint". Or "I'm doing complex animation X, but am not triggering hardware acceleration." Reflows are very expensive. So are repaints. Chrome dev tools will allow you to detect issues with both of those.
- tyleregeto 13y ago
  There are a couple of excellent videos on developers.google.com that dig into this a little bit. I highly recommend watching the following video where two Google developers analyze some real world sites and fix the performance issues: http://www.youtube.com/watch?v=z0_jD8nO5Zw http://www.youtube.com/watch?v=z0_jD8nO5Zw There are some great tips in it.
kellegous 13y ago
I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType. Just looking at their implementations in WebKit should tell you why: https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/Element.cpp#L638 https://github.com/WebKit/webkit/blob/master/Source/WebCore/... https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/Element.cpp#L327 https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
- esailija 13y ago
  Also, the code doesn't call into DOM directly but uses jQuery .html() for "reading" and .html(Math.random()) for "writing". The case is extremely misrepresented indeed.
  - AsymetricCom 13y ago
    The DOM is a failed institution trying to grab on the the ledge before it falls into the abyss. W3C should be disbanded and HTML5 abandoned. JavaScript and it's ilk should be boycotted by users as well. This kind of complexity should exist on the server, not in the browser. I understand that people want to run complex apps in the browser. It's a bad idea in general but where it's needed, it should be PLATFORM DEPENDENT, implementing the tools that keep that platform safe. ie iOS, Windows, whatever. We are still in the browser wars, why are we so keen to adopt standards that aren't standard? DOM Lvl 4 even features GC! Can we not see why this is a bad idea?!? Keyboard bindings also do not belong in a "standard". I wish this would get more attention by serious developers, but I think that most people who know better wouldn't care and aren't interested in understanding and digging into a lame standard. It's a land grab, only enterprises can and will ever be able to implement it correctly and completely, as the standard spreads to consume more of the user's space. Here are some people who agree with me: http://www.adamcrume.com/blog/archive/2009/12/23/the-java-dom-api-sucks http://www.adamcrume.com/blog/archive/2009/12/23/the-java-do... http://programmers.stackexchange.com/questions/147451/whats-so-bad-about-the-dom http://programmers.stackexchange.com/questions/147451/whats-...
chime 13y ago
Did not know Underscore comes with a debounce function. I always implemented my own.
- saraid216 13y ago
  There is also a _.throttle
eagsalazar2 13y ago
TL;DR: Writing is slower, debounce resize event handlers, cache references to dom nodes or jquery selections. Really the resize thing is sort of bs also because it is such an incredibly rare thing to handle (99% of all apps will never ever require handling resize except to test responsive designs)
ihsw 13y ago
Most DOM performance issues arise from jQuery (mis)usage, and fortunately there is documentation for that: http://learn.jquery.com/performance/ http://learn.jquery.com/performance/ It's brief and quite informative.

90 points by andyshora 13y ago

After 10+ years as a performance leaning C++ desktop app developer I'm looking for any and all tips to make JavaScript (jQuery too) work in perceivably faster ways. I'm use to threading database calls, using message queues, and views updating themselves from caches. It’s a new world for me and feels somewhat like a step backwards. Here I come html5!

TheAceOfHearts 13y ago
The only thing that matters in most cases is that it's being done over 60FPS. Use Chrome Dev Tools and to monitor the framerate.
oscilloscope 13y ago
You can use queues when creating a large number of elements. Use requestAnimationFrame and each frame pop some elements off the queue to render them. This will help prevent the page from locking up during render events.
- PavlovsCat 13y ago
  Also, when adding many elements (or not so many, but over and over), add them to a DocumentFragment [ http://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment http://developer.mozilla.org/en-US/docs/Web/API/DocumentFrag... ] first, and then attach that to the DOM in one piece (one big DOM update is better than many small ones).
hising 13y ago
I guess knowledge like yours are important in making better tools and patterns available for JavaScript developers who haven't yet had the opportunity to work with those types of tools, patterns and languages you have. A big opportunity for people who come from more mature environments to share their knowledge!
ivanca 13y ago
For performance any platform is a step backwards, the leveling for easier/broader access is never free.
- fuckjavascript 13y ago
  Rubbish. "Leveling" done in userspace (e.g. libraries) doesn't create a fundamental step back. The browser is just a horribly designed, and why, in spite of years of procrastination and denial - and HN is no exception - it has ultimately ended up as a virtual machine combined with basic primitives (albeit years too late and not done very well at all). My hellbanning on this site is a great example of why this site sucks. How many of the losers who hang out on this site all day collecting karma (as opposed to.. programming) called these problems? Practically nobody, and yet HN is deprived of my wisdom because I am too blunt and don't have an established account.
tlarkworthy 13y ago
try angular JS for self updating views.
slacka 13y ago
Avoiding writes to the DOM is a good tip for beginners. As a desktop developer, you're going to realize quickly that DOM is decent model for documents, but a terrible paradigm for interactive applications. Overall performance is terrible and varies widely between browsers. We either need a new standard or a DOM browser battle like what happened with JavaScript, bringing it from 100x to 3x of native.

bkjelden 13y ago

Caching jQuery selectors may result in a speedup, but as with all caching systems I've run into nasty, hard to trace bugs that were the result of stale cached jQuery selectors. So I'd add the caveat to caching jQuery selectors that standard premature optimization rules still apply.

bdg 13y ago
Caching them in local fucntion scope should be harmless. For instance: grabbing #x, using it inside a decision structure and iterator. Caching #x as a global constant is probably setting you up for some fun debuging later.

Semiapies 13y ago

These timings are all remarkably random, even with 10k repetitions.

esailija 13y ago
In both selector tests, the code calls `.html()` as well. It also uses a direct #id selector, I.E. does not "search the entire DOM" like it says.

malandrew 13y ago

No discussion of repaint and reflow? You can't leave a discussion of those out when talking about the cost of DOM manipulation. You absolutely can touch the DOM, but should do so through and interface that manages or eliminates repaint and reflow.

ghostdiver 13y ago
I have same feeling, Making single frame of JS code to run fast is cool and dandy, but eventually browser will have to make freeze and do reflow+repaint. Eventually it will make profiling harder, think about caching .offsetHeight etc. properties. It does decrease script execution time, but it does not make your app to work faster.
- jcampbell1 13y ago
  The important trick to know is, don't mix DOM modification with DOM measurement. Measuring the DOM is what triggers the DOM modification queue to get flushed. if you do something like $('a').each(function(k,e){ $(e).append('<span>' ...); var width = $(e).width() // do something with the width; } If you have code like the above, it is going to cause a repaint on each iteration. If you unroll it into three separate loops, one that does dom modification, one that does dom measurement, and another that does modification, then you will drop the number of repaints from potentially 100s to just 2.
  - ghostdiver 13y ago
    It does not trigger repaint on each iteration.

ender7 13y ago

The real hits to performance do not come from "I did X writes" or "I did Y reads", but rather from situations such as "I did X writes interleaved with Y reads, which caused Z reflows". Or "I needed to update a tiny part of the screen but triggered a full-page repaint". Or "I'm doing complex animation X, but am not triggering hardware acceleration." Reflows are very expensive. So are repaints. Chrome dev tools will allow you to detect issues with both of those.

tyleregeto 13y ago
There are a couple of excellent videos on developers.google.com that dig into this a little bit. I highly recommend watching the following video where two Google developers analyze some real world sites and fix the performance issues: http://www.youtube.com/watch?v=z0_jD8nO5Zw http://www.youtube.com/watch?v=z0_jD8nO5Zw There are some great tips in it.

kellegous 13y ago

I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType. Just looking at their implementations in WebKit should tell you why: https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/Element.cpp#L638 https://github.com/WebKit/webkit/blob/master/Source/WebCore/... https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/Element.cpp#L327 https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

esailija 13y ago
Also, the code doesn't call into DOM directly but uses jQuery .html() for "reading" and .html(Math.random()) for "writing". The case is extremely misrepresented indeed.
- AsymetricCom 13y ago
  The DOM is a failed institution trying to grab on the the ledge before it falls into the abyss. W3C should be disbanded and HTML5 abandoned. JavaScript and it's ilk should be boycotted by users as well. This kind of complexity should exist on the server, not in the browser. I understand that people want to run complex apps in the browser. It's a bad idea in general but where it's needed, it should be PLATFORM DEPENDENT, implementing the tools that keep that platform safe. ie iOS, Windows, whatever. We are still in the browser wars, why are we so keen to adopt standards that aren't standard? DOM Lvl 4 even features GC! Can we not see why this is a bad idea?!? Keyboard bindings also do not belong in a "standard". I wish this would get more attention by serious developers, but I think that most people who know better wouldn't care and aren't interested in understanding and digging into a lame standard. It's a land grab, only enterprises can and will ever be able to implement it correctly and completely, as the standard spreads to consume more of the user's space. Here are some people who agree with me: http://www.adamcrume.com/blog/archive/2009/12/23/the-java-dom-api-sucks http://www.adamcrume.com/blog/archive/2009/12/23/the-java-do... http://programmers.stackexchange.com/questions/147451/whats-so-bad-about-the-dom http://programmers.stackexchange.com/questions/147451/whats-...

chime 13y ago

Did not know Underscore comes with a debounce function. I always implemented my own.

saraid216 13y ago
There is also a _.throttle

eagsalazar2 13y ago

TL;DR: Writing is slower, debounce resize event handlers, cache references to dom nodes or jquery selections. Really the resize thing is sort of bs also because it is such an incredibly rare thing to handle (99% of all apps will never ever require handling resize except to test responsive designs)

ihsw 13y ago

Most DOM performance issues arise from jQuery (mis)usage, and fortunately there is documentation for that: http://learn.jquery.com/performance/ http://learn.jquery.com/performance/ It's brief and quite informative.