IIRC both Google's and Mozilla's browser metrics showed that a vast majority of users (>90%) never open more than 5 tabs simultaneously. Chrome is optimized for this use case, both from a memory as well as interface perspective. So for most users it works very well, better than the competition I daresay. Unfortunately it tends to completely break down once you go too far out of its comfort zone (i.e. using many tabs). Unless you have immense amounts of memory (> 4 GB) the gigantic memory use will not only affect Chrome itself but also all other programs as the OS starts swapping their pages onto the hard disk (which have to be swapped back upon access which is slow). Additionally, the interface was clearly never intended to be used with too many tabs as it lacks any kind of tab overflow concept. And the interface starts to lack badly which for me is an indication that there are bottlenecks in the single browser process which handles the UI.

Firefox behaves far more gracefully in less regular use cases. With tab groups, switch-to-tab, don't load until selected and tab overflow I can easily have dozens of open tabs without affecting the performance of Firefox and the system too much while remaining quite convenient to use. Mozilla just has to improve the regular use case to be in a better competitive position. Once they've achieved this Firefox will be usable by a far wider range of possible users than Chrome.

Oh, and one of the reasons for Chrome's success (besides the sneaky bundling stuff) is probably the extremely convenient silent updater. I've installed Chrome on many computers which belong to people with little technical knowledge so I wouldn't have to bother with browser updates (users have no say in this) and outdated Flash versions (since it is bundled). Now, the latter reason wouldn't be necessary if Adobe wouldn't be such a bag of fail but that's another topic.

You're right, but most people will not notice Chrome's sluggishness because Google has worked very hard to ensure Chrome feels fast. That, and (in my experience) the fact that most Chrome users rarely go beyond 15-20 open tabs, make Chrome an overall better experience than Firefox for many people. In UX design, perception of speed counts almost as much as actual speed.

The key for that is that the UI is in a separate process. Firefox for android (Nightly and Aurora) also do that.

Of course Chrome also has a process per tab (and in fact a few more than that), but the main thing is really a separate UI process (or lockless thread for that matter).

Interestingly this is also what made BeOS so snappy. All BeOS apps require an UI thread that is separated from the rest.

All that to say, while Firefox probably won't get a process per tab, I'd like if they ported the Android UI process to the Desktop.

Actually in Firefox for Android the UI is just on a different thread than the web content, not in a different process.

V8 is ACTUALLY fast and has been for years. I don't know how that could even be contested. Mozilla internally knows that v8 was/is fast and has been trying to beat them.

Chrome does use more memory if you have a ton of tabs open, but it also is still fast. I haven't noticed a substantial amount of memory leakage, but I guess that depends. Regardless, the memory leakage can be subdued by reopening a tab rather than reopening the app.

The marketing that Mozilla puts out is the problem, not Google's marketing.

http://arewefastyet.com/old-awfy.php

http://arewefastyet.com/

I am quite aware of v8 and how Mozilla is "trying to beat them". I worked on Firefox's JIT.

As it turns out, the optimizations in v8 don't do very much above the baseline JIT except in careful microbenchmarks: https://www.cs.cmu.edu/~ishafer/compilers/files/report.pdf

The difference in speed between the two browsers in real-world code is quite minimal.

I've noticed substantial improvement using Chrome in real-world use cases. The optimizations I've experienced happen in larger apps that hold much more in memory (I don't consider Facebook/Gmail/Wordpress especially object intensive or CPU intensive, do you?).

Speaking historically, you would say that Firefox 3.5 was as fast as Chrome 3 in real-world use cases? Or that Firefox 4 paralleled Chrome 10? Mozilla has been pushing that they're faster, better, ahead-of-the-curve for years and many people have switched because they haven't delivered until very recently.

Maybe only 10% of that is due to the JIT compiler but you can't easily say Chrome hasn't been faster for an extended period of time since it was released. I'm unsure of whether the remaining 90% is due to DOM interaction, rendering, or just perceived crappiness but it exists nonetheless.

"I'm unsure of whether the remaining 90% is due to DOM interaction, rendering, or just perceived crappiness but it exists nonetheless."

A mix of all of that. For the DOM part Mozilla is developing new bindings (called Paris bindings) to close the performance gap compared to the competition [1]. Johnny Stenbeck has written two articles which give an interesting insight into past, present and future DOM bindings in Gecko [2][3]. Azure is Mozilla's new rendering API which even in its infancy showed some promising performance improvements [4][5]. Unfortunately work on Azure hasn't been progressing as fast as I had hoped. AFAIK only the canvas element is currently using Azure for rendering, the rest (ui + content) is still based on legacy APIs. On the JavaScript front there's IonMonkey, a brand new JIT compiler developed from scratch [6]. It's still in ongoing development and lacks many optimizations so right now it's slower than Mozilla's current JIT compilers in many tests [7].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=580070 [2] http://jstenback.wordpress.com/2012/04/07/history-of-mozilla... [3] http://jstenback.wordpress.com/2012/04/11/new-dom-bindings/ [4] http://blog.mozilla.org/joe/2011/04/26/introducing-the-azure... [5] http://www.basschouten.com/blog1.php/comparing-performance-a... [6] https://wiki.mozilla.org/IonMonkey [7] http://arewefastyet.com/?a=b&view=regress

Also relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=539356

That bug is getting close to being done. It fixes a lot of crappyness with excessive layout reflows and painting.

You can see how sometimes Gecko will reflow a much larger area than needed by setting nglayout.debug.paint_flashing to true or installing the following addon: https://addons.mozilla.org/en-US/firefox/addon/toggle-paint-...

Notable cases of excessive reflows: Hovering over the sidebar links in gmail (updates almost the entire page on each hover) Hovering over "related videos" links on youtube (updates all of the related videos area, area around the video, video description, and comment area) A lot of the javascript powered animations/slideshows you see on web pages. (Again, its not uncommon to see almost the entire page being updated here) A few IE test drive tests like BetaFishIE, Santa's workshop, and the CSS maze solver.

When the above bug is fixed, Gecko should be much better in all of these cases.

> I've noticed substantial improvement using Chrome in real-world use cases.

And I've noticed Chrome hits the disk more often when switching between tabs than Firefox does, which makes my real-world use cases a lot slower.

That's pretty much my experience, with one additional issue that really keeps me coming back to Firefox: Chrome doesn't handle sleep and wake-up well.

Ironically, one of the applications that suffers most from this is Google Apps. I'll have calendar, gmail and half a dozen spreadsheets and documents open, move to another room, re-open the Macbook and Chrome dies on all the tabs. Firefox has no problem with this.

On Linux and Windows, Chrome used to be significantly faster. Especially on Linux, where Firefox was honestly miserable to use. Now it's just a little bit faster to start up, and is just a little bit snappier.

The OS X ports of both browsers are a little bit infamous for being iffy, aren't they?