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.
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.
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.
But if I understood correctly that could be finally fixed in upcoming releases.
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.
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.
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.
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...
From a developers standpoint it does. From a "health of the web" standpoint it does also.