5 ms·

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 t

by bokan 9y ago

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 9y ago
> 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.
- bokan 9y ago
  > 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 :).
  - 9y ago
deleted 9y ago
[deleted]
vatotemking 9y ago
I dunno why you are downvoted for such a valid comment. Exactly my point.

by bokan 9y ago

pcwalton 9y ago

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

bokan 9y ago
> 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 :).
- 9y ago

deleted 9y ago

[deleted]

vatotemking 9y ago

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