[laurent123456]

Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome.

We are slowly getting back to the way things were with IE, but I hope that Mozilla won't give up and switch to blink or webkit like everybody else.

[O1111OOO]

> Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome.

Anecdotally.. Firefox was always slower rendering pages compared to other browsers. On some sites that I visited regularly, using FF was depressing. Later on, it started to suffer from caching issues on my machine. This caused a massive system slowdown.

Tried Palemoon (non-blink\webkit, etc). It blazed through pages- even the heavy ones FF had problems with historically. The rendered results were spot on too. It was like getting a new machine.

What I'm saying is that we can't blame everything on pages being optimized for Browser X or Browser Y. Sometimes we need to call out our favorite browsing application and let them know this is an issue. Otherwise, they keep losing users based solely on performance.

Having said that, looking forward to Quantum.

[gonehome]

I'd check out the Firefox nightly which now has all the Quantum stuff - it's a lot better.

I also switched to chrome back when Firefox was a lot slower, but now I'm tempted to switch to Firefox or Safari and I try to occasionally.

I've historically had to switch back partly because I (stupidly) rely a lot on chrome's omnibox autofill memory and also because we use the switchyomega plugin at work and I don't want to deal with having a non-standard setup.

[cosarara97]

I thought Palemoon was basically firefox?

[dingo_bat]

With some ugly UI stuff pulled out and some extra compiler optimisation flags set.

[nicoburns]

That is definitely not true. Firefox 57 is about as fast as chrome, and Firefox 59 may well overtake, but chrome has genuinely been faster than Firefox for a long time.

[AHTERIX5000]

I don't really care that much about how many ms of difference there is in page rendering between the two but blocking UI is a different thing. Still in 56 with no legacy extensions UI blocks from time to time, switching between tabs is slower than in Chrome and scrolling blocks more often.

But if I understood correctly that could be finally fixed in upcoming releases.

[GordonS]

I'm curious as to how you can optimise a site to be faster specifically for Chrome?

[bzbarsky]

Some ways it can happen:

1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.

2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.

3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.

4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.

5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.

That sort of thing.

Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...

[ballenf]

A trivial example is that a 'for' loop vs. 'while' loop can be faster on one browser compared to another.

These differences are even starker if you use newer features without polyfills. For example, 'forEach' implementations as of a year ago varied by orders of magnitude.

Native array sorting is another obvious one. Chrome, Firefox and especially Safari use quite different algorithms each based on array size with varying results.

If you add up all those little changes and always go with the option that's fastest in Chromium, in a reasonably complex SPA you could easily generate noticeable differences.

[cortesoft]

If 'for' and 'while' loops vary in speed that much between browsers, isn't that a defect in the browser? If one way is faster in chrome than firefox, why doesn't firefox change how it is doing the slower version?

[ballenf]

Because that would likely mean slowing down a different scenario. It's usually a trade-off, not a "defect".

The array sorting is a great example where the length of the array chosen or the pre-sort ordering can affect which browser is faster. No single browser may be able to claim the fastest for every scenario.

[laurent123456]

I don't write JS-heavy websites these days so I don't have a technical example to give, but for instance I've opened the Vue cinema website recently on Firefox mobile. The thing was unusable - when I typed my postcode, nothing would show up on screen, the whole website seemed frozen while waiting to load something. I had to press several times certain buttons for something to happen.

On Chrome however everything worked fine right away. Overall it was just a few images, some text and a search bar, so no matter the performances of the browser that should work everywhere, but since it was probably only tested on Chrome and Safari, it only worked in these browsers.

[adzm]

Optimize for the v8 engine and/or browser-specific errata like the way chrome handles composition or svg etc.

[cortesoft]

If most websites are faster on chrome than on firefox, why does it matter that the reason is people optimize for chrome? An end user doesn't care WHY chrome is faster, just that it is for their usage.

[abritinthebay]

From a users standpoint - no it doesn't matter.

From a developers standpoint it does. From a "health of the web" standpoint it does also.