[bokan]

The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web.

Disclaimer: I work on Chrome.

[pcwalton]

> Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques.

This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).

The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo.

The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.

To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.

[stupidcar]

I have never implemented a custom layout in JS because the browser's layout is slow. My JS-based layouts are always slower than using CSS.

I do layout in JS because the existing layout capabilities don't cover my use cases. I create complicated visualisations in SVG, and SVG's layout capabilities are so pathetically anaemic that I have no choice but to take over and use a mixture of D3 and custom JS to arrange things.

Similarly, I don't do synchronous layouts because I'm a moron who doesn't understand performance, but because I need to measure the size of various data-bound elements and feed those dimensions back into my custom multi-pass layout algorithm.

AFAIK, Houdini is an actual attempt to solve both of these problems: It will let run my custom layout algorithm in a worklet, and give it access to the font metrics and element sizes it needs to run efficiently.

The Houdini people seem to be the only web platform people who actually "get it" with respect to these kind of problems. Everyone else seems to be either ignorant or dismissive that these problems even exist.

[pcwalton]

If you're actually using Houdini for custom layouts (including SVG—SVG doesn't really have any layout at all), then I don't have a problem with it. My issue is more with the performance-oriented Houdini specs, for example Animation Worklet.

[roca]

I think that's a bit unfair to Houdini. As others noted here, one of the main goals for Houdini is to make CSS cleanly extensible, so every time some cool new feature comes along you don't have to choose between a) waiting for it to be standardized and implemented in browsers and b) abandoning CSS entirely.

Of course, I agree with the rest of your points.

[pcwalton]

That's fair. I don't have an issue with Houdini if it's actually used to create custom layouts that you can't reasonably do in CSS.

[bokan]

> which means that layout performance affects what looks like script time

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.

> And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).

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.

> If layout were fast, we wouldn't see people implementing layouts in JS

Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster.

> If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.

I disagree. Developers will always find something to fill it with. 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 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.

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. Lets all innovate independently and let the results speak for themselves :).

[roca]

> I think this is a great example of how having multiple rendering engines is healthy for the web.

Yeah, it's too bad that Google's Chrome-first/Chrome-only approach to Web development these days is making that increasingly difficult to sustain.

[pcwalton]

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

[vatotemking]

I dunno why you are downvoted for such a valid comment. Exactly my point.