The bottleneck varies depending on the specifics of the JS, DOM and CSS. I find that when something is slow the culprit is usually someone doing something dumb

The bottleneck varies depending on the specifics of the JS, DOM and CSS. I find that when something is slow the culprit is usually someone doing something dumb in JS. For non-dumb causes, layout is usually the bottleneck (reflow, applying styles, building the display list) but it can be other things. As an example, I worked on a site 5 years ago or so where the bottleneck was on paint, mostly due to lots of shadows. I believe caching of rendered shadows has made its way into most engines but it caused us issues at the time. Mozilla has been doing a lot of work on this front. The Servo project demonstrated you can do style and reflow in parallel. Pieces of that effort have been pulled into Firefox under the "Quantum" label but not the actual reflow part. They're in the process of finishing and incorporating WebRender to make paint more efficient and GPU driven and there have also been efforts at building new drawing APIs (PathTracer, Lyon) as part of that project. I know Chrome had been doing experiments with implementing DOM methods in Javascript to avoid having to cross the JS/C++ barrier in v8 but I haven't heard about that in a while nor any other major DOM-related perf projects out of them. Fairly long answer to a short question. If the new APIs retain the synchronous nature of the current DOM APIs where reads against the DOM state force previous DOM manipulations are blocked until a forced layout happens (I hope they are) then it'll still be possible to DOM thrash and kill your perf that way. I also suspect there's enough overhead in JS->DOM calls that WASM could pick up a double digit perf gain in microbenchmarks but not an order of magnitude with the caveat that's a fairly uninformed guess.