Chrome vs Firefox vs Safari vs Servo WebRender
Jake ArchibaldCited 7× on HN, 2016-2018
121K views · 10 years ago · demo · dated
A short side-by-side recording by Jake Archibald of the same animation demo running in Chrome, Firefox, Safari and Servo WebRender nightlies on a 60Hz display. It shows the smoothness difference of GPU-based rendering.
Used as a quick visual benchmark of the performance gain WebRender brings in Firefox and Servo discussions.
15:00Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 1: Rust
𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮
19K views • 10 years ago
13:44Fastest browser engine by far at 500 FPS! Servo Webrender - CSS on the GPU part 2: Demo
𝓖𝓷𝓸𝓶𝓮💫𝓢𝓪𝓷𝓮
13K views • 10 years ago
45:05Servo Architecture: Safety and Performance
linux conf au 2017 - Hobart, Australia
12K views • 9 years ago
29:47The Truth about Rust/WebAssembly Performance
Greg Johnston
218K views • 3 years ago
35:42Progressive Performance (Chrome Dev Summit 2016)
Chrome for Developers
34K views • 10 years ago
45:49Breaking the 1000ms Time to Glass Mobile Barrier
InfoQ
104K views • 13 years ago
1:00:34High Performance Web Sites and YSlow
Google TechTalks
90K views • 18 years ago
43:29Servo: Building a Parallel Browser
Linux.conf.au 2015 -- Auckland, New Zealand
23K views • 11 years ago
13:39How is this Website so fast!?
Wes Bos
2.4M views • 2 years ago
29:51Refterm v2 - Resource usage, binary splat, glyph sizing, and more
Molly Rocket
68K views • 5 years ago
56:23Speed Up Your JavaScript
Google TechTalks
136K views • 17 years ago
31:17React.js Conf 2015 - Hype!
Meta Developers
108K views • 11 years ago
27:43Bringing SIMD to the Web via Dart
InfoQ
11K views • 13 years ago
25:55React.js Conf 2015 - Beyond the DOM: How Netflix plans to enhance your television experience
Meta Developers
26K views • 11 years ago
13:45A 10x faster TypeScript
Microsoft Developer
608K views • 1 year ago
35:12Jake Archibald on the web browser event loop, setTimeout, micro tasks, requestAnimationFrame, ...
JSConf
808K views • 8 years ago
47:34RailsConf 2011: Aaron Patterson, "Double Dream Hands: So Intense!"
O'Reilly
26K views • 15 years ago
0:56Classic Teams vs new Teams side by side video
Microsoft Teams
64K views • 3 years ago
9:43Meteor Screecast
meteorscreencasts
50K views • 14 years ago
51:04[EPILEPSY WARNING] How fast should an unoptimized terminal run?
Molly Rocket
193K views • 5 years ago
7 comments from Hacker News
Servo is nowhere near ready. It's been a few months since I've seen actual results, but I'd be surprised, if it nowadays completed ACID3 (which was state of the art for browsers in 2009). The thing is that rewriting a browser engine doesn't just happen over night. No bigger browser engine has been written from scratch since the previous millennium. Also, no browser engine implements all currently specified webstandards. So, Mozilla would have to full-pelt develop Gecko to be able to keep up with Blink in webstandards, and then also develop Servo at more than full-pelt to be able to catch up in finite time. That just doesn't add up, which is why Servo was specifically started as a research project. It might never be completed. They have been able to integrate various components from Servo directly into Gecko, therefore sharing the development work which they didn't really plan with, so that's one tiny reason to still hope for it to ever catch up, but yeah, just don't be too optimistic. Having said all that, the integration of components from Servo into Gecko isn't done yet. WebRender is still missing, which should bring another good performance boost. It's sort of been overhyped with artificially complicated CSS animations [0], so the real world effect isn't that big, but it's still very much noticeable. [0]: ▶ this video Aside from that, on Android, Mozilla is building a new framework for building Android browsers in general, called "android-components", which also includes a much
Well, as it says in the article, Firefox and Chrome on iOS are both just WebKit wrappers, because Apple doesn't allow other browser engines into their store, so I don't know what kind of black magic or bias or whatnot your users are experiencing. As for Android, the new CSS engine (called "Quantum CSS" or "Stylo"), which landed with Firefox 57 on the desktop, should ship on Android with Firefox 59. There's also "Quantum Render" or "WebRender" upcoming somewhen soonish. I'm guessing Firefox 60 or 61 on the desktop, so maybe again with a small delay then on Android, I don't know. WebRender should be kind of a big deal. In extreme cases, the difference can look like this: ▶ this video
I have it enabled on one of my Firefox profiles. Would not yet recommend for normal browsing, there's still rendering errors and sometimes seemingly random performance drops, but you can definitely see it working. That is, I have to be lucky for this benchmark [1] to not crash my "regular" Firefox Nightly. With WebRender on the other hand, the benchmark becomes entirely unimpressive, as if you were just playing a pre-rendered video. My system has an Intel i5-3220M with HD Graphics 4000 (was midrange for a laptop in 2012) and 4GiB RAM. OS is openSUSE Tumbleweed with a KDE Plasma + bspwm combination as desktop environment, so no desktop compositor (no idea if that makes a difference). [1] ▶ this video
The CSS engine was completely rewritten in Rust and now heavily utilizes parallelism, which Rust certainly did help with. I'd say, this was only about 1/4 of the performance increase going from 56 to 57, though. (Based on my perception, having run Nightly as daily driver and being aware of when which bigger change got merged.) The rest of the performance work was untied from Rust, as far as I'm aware. Upcoming somewhen after 57 is also WebRender / Quantum Render, which should give a significant boost to FPS. Basically, if you've ever wondered why your gaming PC can render out giant space warfares at 120 FPS, but your browser starts stuttering when that super cool menu animates itself, WebRender is going to fix that in principle. So, there's still going to be other problems, like JavaScript performance just not being on par with compiled code, but it should bring us a lot closer to the FPS that you'd expect. (To throw in some technical terms, in case you want to research: Browsers so far used Immediate Mode to draw things, whereas WebRender and video games use Retained Mode.) And WebRender was architectured as part of Servo, so is also written in Rust, but I can't tell you, if Rust really benefitted work here, or if it just happens to be written in Rust. This illustrates the sort of difference we're looking at with WebRender: ▶ this video (Mind, though, that the video is more than a year old now. Firefox 57 should also already perform a lot better than what is shown in the video. T
> "Which is unlikely to happen anytime soon." Mozilla are moving Servo's WebRender over to Firefox. The feature is called Quantum Render, you can read up about it here: link To give some idea of what this means for CSS animation performance: ▶ this video
See this demo comparing Chrome, Firefox and Servo WebRender: ▶ this video Servo WebRender uses the GPU making it much faster than classic renderers (besides CPU parallelism), think of it like a Webbrowser using Video Gaming technology. There's a talk about this at link (HN discussion: link ) browser.html is just the current "skin" for Servo.
> The UI is rendered with the browser's rendering engine. Yes, the performance will matter. But as Servo demonstrates there are a lot of speed gains to be made with the right design. See this talk by Patrick Walton about Servo's WebRender: link And this short demo comparing Chrome, Firefox, Safari, and Servo: ▶ this video