Firefox 3 Beta 4, memory usage, and what this beta release means for mobile

In between the beta 3 and beta 4 releases we have made some pretty impressive improvements to the browser. The investment that our community has made is really starting to pay off. We’re in the final stretch now to a final Firefox 3 release and we’ve been very focused on making sure that our users are going to have what we are calling a “no compromises experience.” That is, no one should be asked to sacrifice web compatibility, performance, size, flexibility or a fantastic user experience in order to use our products. And I think that this beta release shows that we’re able to do just that.

In terms of performance, people have really started to notice how our changes in the run-up to Firefox 3 have really been making a huge difference on a lot of benchmarks. You can really feel the difference this makes. For someone like me who lives on the Firefox 3 nightlies I’ve become somewhat immune to the changes. But every once in a while I’ll go back to using Firefox 2 and I’m suddenly reminded of how much better we’ve gotten over the last couple of months. The effects are subtle, but important. Pages load instantly, zimbra and gmail respond like desktop apps, the UI is much more responsive – just about everything has improved. People used to complain that our UI felt sluggish because a lot of it is rendered through Gecko, but I think that this release will change that perception. Our new native look has a native feel as well.

Memory usage is one of the most difficult things in computing to deal with. Complex systems like Mozilla resist accurate measurement. End user perception is often skewed by poor tools on the operating systems. Browsers have such different usage patterns from user to user that it’s hard to come up with accurate test cases. And in the end the solutions to problems are not often found where you would expect. In the run-up to Firefox 3, we’ve been investing heavily in improving both our top line size but also how predictable our memory usage is. Stuart has an absolutely fantastic post that covers all of the work that we’ve done in this release cycle to the browser. (And it has graphs if you’re in a hurry – so just go look at it.) Everything from allocator changes to platform changes to focused changes where we’ve found hotspots, etc. There is no one solution to memory usage. It requires a commitment across the project to make it a priority. And it must be measured constantly. We’ve made that commitment.

So what does this mean in a mobile context? It’s pretty simple, really. What it shows to anyone who looks is that we’re able to hit the kinds of memory and performance requirements that mobile platforms demand. Along with that we’re able to bring our full platform, excellent web compatibility, a single source code base, a committed organization and a strong brand and identity and make that available to partners and users. Users who use our software on mobile devices can expect web sites that just work, access to add-ons all balanced against the hardware limits imposed by mobile devices. In essence, we can bring that no compromises approach to mobile, just as we’ve done it with the desktop. And Beta 4 is the proof of that.