Handmade Network»Forums»Why so slow?
Ben Visness
106 posts / 6 projects
HMN lead.
Why is the DOM so slow?
Edited by Ben Visness on

I don't understand why the DOM is so slow. It's well-known that it is slow, of course - this is why React has its "shadow DOM" and does diffs before performing real DOM operations. But - why? Why should it be so slow to add elements and so slow to access them? Why couldn't React do its diffs against the real DOM? etc.

I made a little benchmark to test simple DOM inserts. It demonstrates a few interesting things, I guess...first, no matter what I do in my tests, getting data into the DOM (not doing a layout and render!) is about 3x slower overall than pushing into a JS array (which I take as the control). Is that reasonable overhead? I'm not really convinced it is for just the data manipulation part of it. And in Firefox, performing updates on the actual DOM instead of using DocumentFragment or innerHTML is dramatically slower.

Firefox results on my PC:

image.png

And Chrome results as well. Chrome seems to have optimized runs of inserts into the actual DOM:

image.png

I would like to know what DOM implementations are actually doing during simple data manipulation. Where is that overhead over plain JS coming from? Closing that gap would make a big difference, and could help us avoid pitfalls in future retained-mode UI systems.

Simon Anciaux
1241 posts
Why is the DOM so slow?

It's probably not easy to do but isn't the source code of firefox and chrome available ?

Bruce Dawson's blog sometimes talks about performance issues in chrome, maybe you could try to contact them to find where to start (I believe they work at google on chrome) ?

https://twitter.com/BruceDawson0xB/

4 posts / 1 project
Why is the DOM so slow?
Edited by synthnostate on

One word: cruft.

The DOM evolved in the (early?) 90s as a structure+API for static HTML page layout, with JS dynamic modification as an afterthought, and it never got a proper overhaul before becoming a de facto standard. I think the API functions have to update a bunch of variables on the C++ side to keep everything consistent; it's basically spaghetti. Someone ought to develop a simple replacement for the WWW so we can nuke it... it's just terrible.

I have a neat little JS GUI in my game that I'm interested in spinning off. While I can't say it's efficient as of now, it has the bare essentials of CSS and HTML in pure JS (with a C render backend) totalling ~3 kloc. Could be useful for making lightweight native applications with many of the advantages of browser/electron apps.

btw, I'm new here - is there some place I should say hello?

6 posts
Why is the DOM so slow?
Edited by nickav on

I don't know if this helps or not, but I remember trying to figure out why the DOM was slow myself when trying to optimize a "big" list of items (~1k+) in React and I wound up having to implement a VirtualList. But one of the things I discovered is you can create an HTML page of ~5000 empty divs and load that page directly and it opens pretty much instantly.

Example:

// Save clipboard as test.html
copy('<div>Hello</div>' + Array.from({ length: 5000 }).map((it) => '<div></div>').join('\n') + '<div>World</div>');

NOTE: that on my machine, if I try to "preallocate" ~10k divs my browser page literally hangs for quite some time.

Now that I think of it I can't remember if document.createElement('div') or .appendChild() was actually the slow thing in the DOM API.

So one possible workaround is to load a page with a bunch of "preallocated" divs. I don't know if the browser will start to slow down again once you try to actually use them though.