from Hacker News

How Bad is DOM Interaction Really?

by andyshora on 8/10/13, 5:10 PM with 33 comments

  • by ender7 on 8/10/13, 6:58 PM

    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.

  • by kellegous on 8/10/13, 7:09 PM

    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/...

    https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

  • by malandrew on 8/10/13, 6:37 PM

    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.

  • by ihsw on 8/10/13, 8:23 PM

    Most DOM performance issues arise from jQuery (mis)usage, and fortunately there is documentation for that:

    http://learn.jquery.com/performance/

    It's brief and quite informative.

  • by pcunite on 8/10/13, 6:16 PM

    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!

  • by bkjelden on 8/10/13, 6:25 PM

    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.

  • by Semiapies on 8/10/13, 6:36 PM

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

  • by eagsalazar2 on 8/10/13, 7:30 PM

    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)

  • by chime on 8/10/13, 7:13 PM

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