Firefox 3.1 could catch up to Safari 4 in beta speed duel
With software continuing to get bulkier and less memory-efficient, the need for speed is re-emerging, and Mozilla could very well deliver.
With the next — though probably not the last — public beta of Firefox 3.1, testers outside of Mozilla will get their first chance to see in action perhaps the number-one reason customers would want to upgrade: the browser’s new TraceMonkey JavaScript execution engine. Expectations have been raised quite high over the past several months, as developers have promised orders of magnitude faster execution of functionally-driven Web pages.
But last week, it was Apple that threw down the gauntlet with its public release of a Safari browser beta, for both Mac and Windows, that tore through the speed records for JavaScript in public betas. Right now, it’s Safari 4 that has the provisional pole. Yesterday, however, Mozilla managers instructed developers to start wrapping up their final check-ins, as it’s nearing time for a public release of Firefox 3.1 Beta 3.
This afternoon, Betanews checked the latest nightly internal build of the code being wrapped up for Beta 3, to see if TraceMonkey was going to make its appearance or be delayed until the next round. We gave the latest build of code-name “Shiretoko” a quick qualification test, and you can almost hear the voice of Tom Carnegie now: “An-n-n-nd…he-e-e-e’s on it! “
Our early test results showed that Firefox 3.1 could, at the very least, make up a lot of ground in the rendering department against Safari. It hasn’t passed Safari’s scores just yet, but if the warm-up laps are any indication, Firefox will join Safari in a neck-and-neck battle for the pole.
We put last night’s “Shiretoko” build through the same battery of tests that we gave the latest Safari 4 beta last week, along with production versions of the other major Windows-based browsers: Google Chrome, Opera, and Internet Explorer. We used the same virtual machine running Windows Vista SP1 in Microsoft Virtual PC, running on an Intel Core 2 Quad Q6600-based host, that we used in our previous tests. This isn’t exactly a superspeedway, but what’s important here are the relative Death Ride aka Haunted Highway movies speeds, which are more pronounced against one another when using a slower environment.
In the HowToCreate.co.uk CSS rendering benchmark, Shiretoko loaded the test page in 456 ms, and completed the rendering test (at first) in 38 ms. But each successive rendering got faster, thanks probably to memory caching, until eventually Shiretoko was capable of rendering the test in 4 ms. This compared to the Safari 4 beta’s score of 54 ms to load and 7 ms to render. We were able to speed up Safari in successive renders as well, until it too hit 4 ms.
By itself, that delta still looks like a gulf. But Firefox 3.0.6 loaded in 400 ms and rendered in 61 ms. If 3.1 can get closer to that 4 ms score in the final public build, it will have made up some critical ground — and in any event, it will look and feel a whole lot faster to a much broader range of users, at least on the Windows side, than Safari.
In Sean Patrick Kane’s collective JavaScript speed battery, Shiretoko completed the battery in 344 ms, which is 32% faster than Firefox 3.0.6 — not orders of magnitude, but still a good boost. Safari 4 beta’s score stands at 174 ms.
And finally, Shiretoko earns some style points along the way by scoring a 93 on the Web Standards Project’s Acid3 standards compliance test. That’s one of Mozilla’s highest scores there to date, with Firefox 3.0.6 only scoring a 71. Of course, you can’t get any better than Safari 4 beta’s score: a perfect 100.
Nightly builds of any kind of software, including open source, tend to have less optimized code than public beta builds, so Shiretoko’s speed increase could be an indication of a more competitive score from Firefox 3.1 Beta 3 down the road.
