By Scott M. Fulton, III, Net1News
Exactly what is it that convinces a Windows 7 user to drop the Web browser that came with her operating system - Internet Explorer - and try one of its many free competitors? The very name "Firefox" implies both speed and savvy, two factors its predecessor - Netscape Navigator - did not always possess. "Faster" and "better looking" are the two factors that make folks trade up for a sports car, though with a Web browser, "free" is a nice incentive you don't find in the automotive market.
Last month, Microsoft demonstrated that it is indeed capable of robbing Firefox of all its persuasion points, with a public beta of IE9 that is faster and smoother than anything Mozilla has ever produced. If IE9 is already fast, simple enough to use, and even good looking, the incentive for consumers to try not just Firefox but any other alternative, could evaporate.
In the most recent browser performance tests conducted by Ingenus LLC on October 8, Mozilla's public beta of Firefox 4.0 Beta 6 continues to lag behind Microsoft's public beta of Internet Explorer 9 by 20% overall. Using the performance of the 2008 model Firefox 3.0.19 as an index (1.000), Mozilla's current stable Firefox 3.6.10 release scores a 2.199 overall, representing better than twice the performance of its predecessor. Firefox 4.0 Beta 6 scores a 3.067 on the same tests; and it should be worth noting that the ability for any mechanical product to gain about 100% performance per year is an extraordinary achievement.
But in a field of extraordinary players, this milestone could get lost in the shadows. IE9 scores a 3.692 on the same suite of tests, catapulting itself over IE8's score of 1.277 and making room for itself as a true contender.
Click the chart above for a complete categorical breakdown
Being just a contender - just capable enough to fight the battle - may be all Microsoft needs to win this war. While not everyone seriously cares about the performance of his Web browser or his refrigerator or his lawnmower, in recent months, the number of folks who do care has grown. Historically, it's the non-caring group that has represented Microsoft's base; in fact, this year the single loudest evangelist preaching the virtues of kicking off the mortal, rotten coil that is IE version 6, has been Microsoft itself, going so far last March as to send flowers to a mock IE6 funeral.
For the other group, the urge to use Anything But Microsoft remains strong, including for office workers who feel stuck with Windows every day. That urge has sustained Mozilla's core customer base up to now. But Mozilla's place as the standard bearer for alternatives is now under concerted attack by all three non-Microsoft rivals, with the smallest of them all carrying the biggest guns to the fight.
An exhaustive battery of tests on the latest developers' snapshot of Opera Software's latest 10.7 reveals a browser better suited for running modern Web applications than even Google's fastest developers' build of Chrome. Last Friday, that snapshot build scored a colossal 5.167 overall, toppling both the 4.419 score posted by the current stable Opera 10.62, and Google Chrome's fastest score: the 4.825 posted by development build 7.0.544.0.
Ingenus' tests account for browser performance in four primary categories: JavaScript computational speed (30%); HTML/DOM text rendering and HTML/SVG/Canvas graphics rendering speeds (30%); "scalability," which Ingenus defines in this context as the ability to maintain or improve performance as workloads scale up (20%); and efficient use of CPU and memory (20%). All of these factors combine to affect perceived page load speeds, but no single test's results can be impacted by the relative speed of the Internet connection, which is an independent and unpredictable variable.
Four years ago, Opera Software lit the fuse that sparked the whole "speed is good" argument in the Web browser field. But Mozilla, Google, and Apple all answered back, leaving Opera behind as an also-ran, even fueling speculation that Opera could just simply quit. IndyCar fans will appreciate this analogy: If Firefox 3.5 was Danica Patrick, Opera 9 was Milka Duno.
Then last spring, Opera changed drivers, changed engines, and changed everything. It introduced a JavaScript engine code-named Carakan that replaced its stack-based processing system with a full slate of registers and a bytecode generator, which is the difference between a pocket calculator and an iPhone. Suddenly Opera had an engine with the ability to digest JavaScript into native code for processors, one big step ahead of the intermediate bytecode that managed code interpreters typically produce. When Opera first announced Carakan in February 2009, developers promised the ability to effectively digest entire segments of JavaScript programs into something that resembled assembly language.
Opera's developers have been more quiet these days than they were last year, but based on what we're seeing from the snapshots, it's because they're very busy. Ingenus' tests indicate that those "entire segments" of code selected for heavy pre-digestion, in the next version 10.7, will include many of the open source JavaScript libraries used by Web apps developers to generate world-class, in-browser applications such as word processors, photo paint utilities, and even movie editors. Web developers who build AJAX apps that listen for local events are adopting the jQuery library more and more; and Opera 10.7's performance with jQuery and several other libraries is nothing short of astonishing.
For its latest tests, Ingenus re-engineered the open source SlickSpeed selectors test to account for the newest versions of JS libraries, and also to give each one more of a workout. The new test battery, which you can see and try for yourself on this page, gauges the amount of time it takes for a browser to process 64 different standard CSS3 selectors, both natively and with the aid of the most recent versions of ten different libraries including jQuery, the popular MooTools, and the latest build of selector engine Sizzle by jQuery creator John Resig.
Opera 10.7's SlickSpeed scores are nothing short of astonishing. Here's the full scale of it in a nutshell: Not long ago, the average CSS3 selector took the jQuery library about 250 ms to execute. When Microsoft unexpectedly threw its support behind jQuery, it improved IE8's performance with that library to approach par for the course. Now IE8 executes a selector with jQuery 1.4.2 in 228.72 ms. Firefox 3.0.19 (the index browser) takes 171.9 ms on average, and Firefox 3.6.10 accelerates that speed all the way to 39.83 ms.
Throwing down the gauntlet, Google Chrome's performance with jQuery of late has seen posted times of between 11 and 12 ms, which just last month would be called astonishing. Opera 10.62 performs well at 20.34 ms, but well behind even Apple Safari 5.0.2 at 16.02 ms.
Here's where Opera 10.7 picks up the gauntlet and throws it overboard, posting an average time of 3.69 ms on average. Other libraries also share in Opera's switch from impulse to warp drive: Sencha's Ext 3.2.1 JS library performance boosts from 20.66 ms (10.62) to 2.98 ms (10.7); NWMatcher 1.2.2 performance surges from 19.79 ms (10.62) to 3.61 ms (10.7); and Resig's Sizzle library finds its powder keg, blasting from 19.4 ms (10.62) to 3.1 ms (10.7).
It's surges like these that lead to Opera 10.7's unbelievable relative score of 20.407 on the new SlickSpeed battery, compared to its nearest rival, the latest stable Google Chrome 6.0.472.63 with 8.822. The latest daily development build of Firefox 4 Beta 8 (less stable than the "public" Beta 6, though still openly downloadable) manages only 3.353 on this same battery.
Next: Opera 10.7's play for efficiency...
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Even Opera's speed gains alone aren't the scariest part of this story. There's two ways to make a car go faster. One is to put your foot on the gas, and the other is to replace its engine with something more efficient. There's a cost involved with the former, as fuel efficiency goes down.
Adding resource efficiency to the browser test score system completely changes the way we analyze Web browsers. When Google Chrome gets faster in recent months, it's because it pushes the accelerator petal down. Now we can measure just how much.
Chrome uses a slick trick to get more power, effectively distributing its workload not just among multiple threads but often to two processes as well. (It apparently has the capability to fork a third, but when we've observed Chrome doing so, it doesn't yet make much use of the third process and typically shuts it down.) Using the Performance Monitor tool now built into Windows 7, Ingenus now monitors the peak and average CPU utilization and memory usage over the time span of its longer tests, including SlickSpeed, and compares those figures against the same consumption rates for the old Firefox 3.0.19.
Up until IE9, Microsoft never really produced a high-performance browser. On the other hand, IE wasn't a fuel hog, either. Like the Chevy Chevette of the 1980s, IE was relatively fuel-efficient, especially when handling small workloads. That's why it scores a 3.899 on the efficiency segment of Ingenus' test battery, and why all other browsers typically go down from there instead of up. With the original 10-iteration-per-selector SlickSpeed test, IE8's efficiency scores were typically good, at or around 1.0. When we bumped the iteration count to 100, IE8 exhausted itself with an efficiency score of 0.644.
Chrome's generally good SlickSpeed scores come at a cost. Google's latest public beta, version 7.0.517.24, posted a relative speed score of 8.189 on the SlickSpeed - a little slower than the stable build, but probably because beta code often contains debugging features that are removed for the stable version. The speed score for the latest not-so-public development build 7.0.544.0 moved up to 8.383. The resource cost for that speed boost is measurable, with memory cycle usage jumping from about 105% to 133% (on a quad-core test system, each core accounts for 100%, so total CPU utilization on Performance Monitor is 400%), and peak memory consumption jumping by almost half. So efficiency scores decline from 1.362 for the public Chrome beta, to 1.254 for the dev build.
Keep in mind that each single point of efficiency is the same as one whole Firefox 3.0. Yes, IE8 is nearly four times more efficient with computer resources than Firefox 3.0 (as Microsoft engineers will probably say, it would have been nice if someone had said that out loud two years ago; and in retrospect, I concur).
Conceivably, Opera 10.7 could have achieved its performance gains by throttling up by 50%, doubling its memory allocation, and throwing on the afterburners. It didn't. Instead, its updated engine sipped CPU cycles at 79% peak utilization and just over 8% average utilization, which in real-world numbers means the new Opera never used more than 20% of a quad-core CPU to process more CSS instructions than it will likely ever need to process in a four-minute period.
The thrills don't stop there. There was a time not long ago, still measurable in months, when the SunSpider test battery was the browser's equivalent of a Marine training obstacle course. Although Opera 10.7 did not post the best SunSpider processing scores (IE9 remains the champion here with a 14.268 compared to 11.995 for Opera 10.7 and an impressive 12.195 for the daily build of Firefox 4 Beta 8), its resource utilization barely moved the needle. Registering just over 9% on the Performance Monitor at its peak, and 4% on average, the Opera dev build actually never used more than 3% of an Intel quad-core CPU to process the entire SunSpider battery.
That's how Opera achieved an efficiency score of 9.696 on the SunSpider, compared to 6.951 for the latest WebKit snapshot running in Safari 5, 4.009 for the latest dev build of Chrome, and 3.986 for IE9. Sure, IE9 has the best speed here, but the Performance Monitor needle can tip the 40% mark (10% actual utilization).
The Opera 10.7 beta's total efficiency score of 4.016 makes it the first browser in Ingenus' tests to score above IE8's benchmark of 3.899, and the very first browser to effectively perform better than what's shipped with Windows without sacrificing efficiency or increasing overall memory use. You lose nothing by switching to Opera, which is something that you could never say for Firefox. Imagine owning a great sports car - a Mustang, Challenger, or Camaro - that you could say sipped gasoline like a Chevette.
Overall scores for Firefox 4 Beta 8 show that Mozilla's engineers are indeed continuing to move forward, scoring a 3.478 overall compared to 2.199 for the stable Firefox 3.6.10. But if Apple's gains with the latest snapshot builds of the WebKit engine are indicative of Safari 5's future, Mozilla could very well find itself later this year minting its final Firefox 4 as the lowest performing stable browser in the top five, taking IE's place on the bottom of the heap. Today, Beta 6 and Beta 8 are posting the lowest scores for any development build browser in the JSBenchmark battery (3.822 for Beta 8 versus 4.368 for Safari 5 + WebKit 69025, with the rest higher), the Ingenus DFScale variable workload battery (3.721 for Beta 8 versus 6.191 for Safari 5.0.2, with the rest higher), and the Man-in-Blue sphere animation battery (1.876 for Beta 6 versus 2.731 for Opera 10.62, with the rest higher.)
What appears to be a change in the test browser's HTML 5 Canvas plotting engine, is responsible for the one bright spot for Mozilla: a big improvement in Firefox 4 Beta 8's overall efficiency score over Beta 6, from 1.728 to 3.346. Computationally speaking, Beta 8 is now a bit faster than the latest Safari/WebKit, with a 6.579 score versus 6.488. That doesn't even compare, however, to the IE9 beta at 7.645.
Beginning now, Ingenus will provide continual updates on Windows 7 browser performance, so you can see for yourself which browser maker has the best performing model right now.
This article originally appeared in Net1News.
©Copyright 2010 Ingenus, LLC.
©Copyright 2010 BetaNews, Inc.
Copyright Betanews, Inc. 2010