Hacker News new | comments | show | ask | jobs | submit login
Why is the DOM slow?
21 points by melsalvador 842 days ago | hide | past | web | 2 comments | favorite
What can be added (or removed) to help to help it approach native responsiveness.

Please note, "just get rid of it" isn't realistic. Given where we are, what can be done, that's the challenge.




Sometime I want to do a big, detailed blog post full of supporting data on this topic. Unfortunately, all the data I have on this I left behind at my ex-employer (Google), and I don't yet have time to write the code to compile new data.

The short answer is that the DOM is not slow. Adding & removing a DOM node is a few pointer swaps, not much more than setting a property on the JS object.

However, layout is slow. When you touch the DOM in any way, you set a dirty bit on the whole tree that tells the browser it needs to figure out where everything goes again. When JS hands control back to the browser, it invokes its layout algorithm (or more technically, it invokes its CSS recalc algorithm, then layout, then repaint, then re-compositing) to redraw the screen. The layout algorithm is quite complex - read the CSS spec to understand some of the rules - and that means it often has to make non-local decisions.

Worse, layout is triggered synchronously by accessing certain properties. Among those are getComputedStyleValue(), getBoundingClientWidth(), .offsetWidth, .offsetHeight, etc, which makes them stupidly easy to run into. Full list is here (possibly a few years out of date):

http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-...

Because of this, a lot of Angular and JQuery code is stupidly slow. One layout will blow your entire frame budget on a mobile device. When I measured Google Instant c. 2013, it caused 13 layouts in one query, and locked up the screen for nearly 2 seconds on a mobile device. (It's since been sped up.)

React doesn't help speed up layout - if you want butter-smooth animations on a mobile web browser, you need to resort to other techniques like limiting everything you do in a frame to operations that can be performed on the GPU. But what it does do is ensure that there is at most one layout performed each time you update the state of the page. That's often quite an improvement on the status quo.

(Standard disclaimer: this was all current as of the beginning of 2014, but browsers change fast, and it may or may not be current now. Much of the current pitiful performance of major JS frameworks is because they were built with assumptions on browser performance that were true in 2008, but aren't now.)


This was a great comment, and I feel like I got a great education reading this. Thanks again.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: