> Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading.
If you can multithread iframes, then I think Amdahl's Law will start to kick in unless you improve style and layout performance. For instance, if I block the ads on washingtonpost.com, then style + layout is nearly as big as script.
But in any case, you have to look at how that affects the user experience. If done properly—i.e. everything remains responsive—the user won't notice slow script very much.
> I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.
Servo definitely does address it, because it runs all cross-origin iframes in separate threads (and has from the beginning). Even same-origin iframes get separate style/layout threads, even though they share the same DOM thread. It can also do process isolation, as ipc-channel lets us abstract over the thread/process distinction.
I think multithreading is a more scalable solution for performance than process isolation, because with process isolation you need heuristics to avoid ballooning the number of processes out of control. You could have a throttled "ad process", but then you'd have to figure out what the ads are and hope you don't mess up, or else you might hurt iframes that matter. It's a lot simpler to just put separate origins in separate threads to begin with.
> Are people re-implementing layout/paint because it's slow?
Yes, because they've been told to use CSS transforms instead of real layout because those "run on the GPU".
> I think it's naive to think developers will just stop writing JS if the browser gets x% faster.
They won't, but we can certainly help things along a lot by making it easier to just use the platform. (I think we're in agreement here.)
> IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.
I agree with the general principle, but I disagree with way it's implemented in existing browsers. The compositor thread is super limited; it's a thing that handles a weird subset of CSS that you have to be careful not to fall out of or else your performance drops. This is no way to treat Web developers! It's a historical accident, too, one that stems from the fact that Core Animation was developed independently of Mobile Safari for the iPhone 2G, Mobile Safari retrofitted a subset of CSS to that API, and then everyone copied Mobile Safari.
It makes more sense to have a dedicated thread for all style and layout and another thread for all painting, eliminating the paint/composite distinction. No matter what you do, the styling/layout runs off main thread, and the painting runs in yet another thread. That's Servo/WebRender's design. It's not easily compatible with existing engines, but that's why Servo exists :)
> I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.
The problem with focusing just on adding new stuff to the platform is that, while Google's evangelism operation is impressive, it's hard to get existing Web developers to move to new stuff. It's the classic Itanium vs. x86 inertia problem. To take Washington Post as an example, they layout thrash like crazy when loading, despite it being known for years that that's a massive performance problem. By contrast, by making existing patterns faster, we improve the user experience for all Web sites, old and new.
To be clear, we should both introduce new APIs (IntersectionObserver is a very important one) and work on improving performance of the old. They're not mutually exclusive.
> In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web.
Oh, it's hardly a silver bullet. Those don't exist. By the same token, though, new APIs and things like AMP aren't a silver bullet either ;)
> I think this is a great example of how having multiple rendering engines is healthy for the web.
I agree, which is why I disagree with the "Chrome Won" defeatist attitude of the article.