Mozilla's Push For Super Fast CSS With Quantum/Stylo

[KellyClowers]

If you don't use NoScript and AdBlock Plus or Ublock Origin, older versions of Firefox were literally 2, 3, or in some cases 10 times slower than Chromium and Chrome on many websites. On some websites it hung completely.

Such Bullshit. Ad blockers or noscript obviously make things faster (including Chrome), but Gecko and Spidermonkey perform fine, and always have. And it has historically seen plenty of perf improvements without tossing XUL and extensions. There is no reason for webextensions to exist except Mozilla's "wahhh, we wish we Chrome, because we like shit software" attitude.

[KellyClowers]

That's the (one) developer's side of the story.
Mozilla's side of the story is they're going for WebExtensions which aren't new and have been available for a while. That is not a moving target.

Lies. WebExtensions are FF. Chrome's are "chrome extensions" and there is no standard, just "whatever chrome does" (I think there may be some movement towards a common standard, but it sure as hell ain't here yet). Plenty of FF extensions are not possible without the FF additions to the Chrome API, so it is a moving target... not to mention even the parts that are the same were not implemented in FF for a long time (hell, are they all there even now? unclear from what I have seen in Bugzilla).

[grok]

All I really care is that FF 57 allows me to put the refresh button on the right of the URL, not the left as I dislike that.

Although a replacement for Nuke Anything will be needed. Try reading an article when a toolbar/ribbon on the web wastes two hundred vertical pixels and doesn't go away.
Among other things, the "copy url" button in Firefox 57 will be useful to open pages like that in Firefox 52 until the new versions are able to deal with them.

[name99]

I've been using this for about two weeks now. Not only is it much faster at rendering pages now, but also fixes a number of bugs with the previous CSS processor (either bugs, or it just implements some newer features that weren't in the old one). It's amazing how much of a difference this has made on performance, despite not having anything to do with page rendering at all.

It's just cascading multiple CSS files together in parallel and handling conflicts with priorities accordingly. So, you won't see any difference in web browser benchmarks, unless those benchmarks are able to measure how fast you can parse a lot of CSS files. CSS-heavy websites like Google+ are much, much more responsive now.

The next step will be getting WebRender working properly, which is coming soon.

There is one benchmark you can try here:
https://webkit.org/blog-files/css-ji...benchmark.html

This was written specifically to test something in Safari (so it's not pretending to be representative of the web), but it does test an aspect of CSS speed. You can read details here:
https://webkit.org/blog/3271/webkit-...-jit-compiler/

Right now, on my iMac, I get 60947 matchings per sec on Safari 10.1.2, and 2111 (ouch!) on Firefox, but I'm using FF 55.0.3 which I assume is still without the optimizations being discussed here.

Another interesting data point is that with Safari on my iPad Pro (A10X) I get 70529 matches/sec, so about 16% faster than Intel iMac (late 2012 Ivy Bridge I7-3770) --- nice work Apple CPU team!

==============
Update: Out of curiosity I downloaded 57 Nightly and the number isn't much different, about 2040.
I wouldn't read too much into this; what's being tested is very much a particular way SAFARI solves the problem of precomputing and caching CSS rules, and the fact that FF does this differently (and so behaves badly in a particular extreme situation) doesn't mean too much. I'd rather have a "real world" CSS test.

On the other hand, I DO think the i7 to A10X comparison is valid, and interesting.

[Tomin]

Update: Out of curiosity I downloaded 57 Nightly and the number isn't much different, about 2040.

Did you tell it to use the new engine? It is not used by default, only when layout.css.servo.enabled is set.

[name99]

There's another interesting benchmark here:

http://browserbench.org/MotionMark/

For this one, iMac Safari gets around 130, FF Nightly gets around 160. Safari A10X gets about 335 and Chrome gets around 350!
It would be easy to say that this represents the iMac screen as being larger, except the iPad is retina, so ultimately has 50% more pixels.
My guess is that represents the A10X CPU being able to communicate with its GPU with substantially less overhead than is possible on the iMac. (The iMac has both an intel GPU and an nV GeForce GTX 675MX; my guess is that it's using the nV part for this benchmark, and obviously that has heavy overhead, though my guess would be that even the communication with the on-SoC Intel GPU is higher overhead than Apple achieves on their part.)

[name99]

Did you tell it to use the new engine? It is not used by default, only when layout.css.servo.enabled is set.

Ah. Thanks.
* Futzes around *
Uhh, how do I do that? Treat me like a 5-yr old child.
Web search provides nothing useful. Search of FF prefs turns up nothing.
Somewhere else I see the string
pref("layout.css.servo.enabled", true)
but no indication as to WHERE I type this in.

=====================

Ahh. Go to about:config page!
Let's see now.
OK, sorry, not much improvement. This time about 2060, so really no different.

[Tomin]

Ah. Thanks.
* Futzes around *
Uhh, how do I do that? Treat me like a 5-yr old child.
Web search provides nothing useful. Search of FF prefs turns up nothing.
Somewhere else I see the string
pref("layout.css.servo.enabled", true)
but no indication as to WHERE I type this in.

Go to about:config page. I recommend to use the search box on that page to find the option. Double clicking changes it.
https://support.mozilla.org/fi/kb/ab...editor-firefox