There's no quick answer to this question because the 'science' of benchmarking phone web browsers against 2010 web sites has become more than a little woolly. Things used to be simple: you'd download the HTML page and then the images and you'd be done. However, we've now got to take into account:
- Flash, Silverlight and other dynamic content types
- adverts, often sourced from ad networks and so you don't get the same advert on every page load, or even from exactly the same source
- other cloud link-ups, mash-ups and various embeddable content from other sites
In short, things are now far more complicated. And that's before you take into account variations in the time of day, other traffic on the Wi-fi networks being used, other traffic on the ISP network providing the bandwidth, and bottlenecks in capacity at the server end.
Which is why I'm not going to attempt a superficially exact set of timings. No tenths of a second here, I've rounded everything to the nearest second or so. What I'm interested in are relative speed differences between the different browsers tested, plus I'll not be able to resist commenting on usability and other standout features as I go.
Before launching into the main table, a few extra notes:
- all timings were over wi-fi, with no other active computers sharing the bandwidth
- all web site renders were of the full desktop site - if a mobile site was offered as a default, I went looking for the link to the full/classic/desktop version. After all, every browser can handle the low bandwidth mobile web - what we're looking to do here is push the browsers to their limits
- the cache of each browser was cleared before the tests
- all browser content settings were left on defaults, except where noted
The Symbian browser tests were all on the Nokia N8, the Android browser test was on the HTC Desire HD. the biggest and the fastest Android 2.2 phone around.
HTC Desire HD and Nokia N8 browsing Wikipedia (in case you're wondering, both displays are set on 'auto brightness')
Oh, and one other very important note. A factor which kept cropping up was in-page ads sourced from various ad networks that took ages to load - in many cases below, a web page would load to a 'usable' state - by which I mean that most content was in place and the browser was responsive to touch control - in a certain time and then there would be another much larger time needed for all the various ads and unimportant bits to finish loading, before the web page was finally 'loaded'. So as not to drag times down across the board in an erratic ad-dependent manner, I've quoted two times below.
For example, "9/16" means that the page was 'usable' in 9 seconds and 'loaded' in 16 seconds. Obviously, the first number is the important one, in terms of usability and perceived browser speed - the second number is more for completeness.
|(all times in seconds)||Web (Symbian^3 default browser)||Opera Mobile 10.1 final with Turbo OFF||Opera Mobile 10.1 final with Turbo ON||Opera Mini 5.1 beta for Symbian||Android 2.2 browser||Safari on iOS 4.2|
|All About Symbian||17/23||7/22||5/23||13/19||7/12||6/22|
|Wikipedia English homepage||12/12||9/9||4/12||6/6||5/12||4/5|
|Bonus test: Sunspider benchmark||n/a***||12034ms||n/a||n/a***||5946ms||8304ms|
|Bonus test: JS Benchmark (larger scores better)||6||25||n/a||17||50||47|
* The full BBC News page insisted on reverting to the mobile version here, so I benchmarked the main homepage rather than the news one. Both had similar layout and design...
** The Engadget home page is the one often used as an example to show up less powerful browsers. While this is a valid test, the page itself is ridiculous. Even the Engadget web team refer to the page as an 'experience'. It involves a nightmarish 3MB plus of HTML, code, images and objects, and even by 2010 standards is a horribly bloated web homepage.
*** Some figures were unavailable, either because the full desktop site refused to be served to the phone or because (in the case of desktop-browser-oriented benchmarks) the test couldn't be completed for compatibility reasons
Having picked the two top competing devices and browsers, I'm not altogether surprised that Safari on the iPhone 4 and the browser on the 1GHz Snapdragon-powered HTC Desire HD were very close as overall winners. I'm somewhat mystified how the iPhone 4 is quite so quick at handing control to the user, other than through great UI coding and, perhaps, knowing that it can ignore certain content types completely (e.g. Flash). Both Apple And Google have made sure that the user has full navigation control (both scrolling and zooming) as soon as humanly possible, whereas the current Web implementation on Symbian seems to almost withhold control from the user until the last possible second.
You should note, however, that all other competing devices (older iPhones, lower powered Android phones, or those running OS 2.1 and before) will be significantly slower - my Orange San Francisco, for example, produced times that were slightly slower than Opera Mobile on my N8.
Talking of which, of the Symbian-based browsers, Opera Mobile 10.1 (final), with Turbo 'on', is probably your best bet. It's almost as quick, on average, as the proxy-based Opera Mini, yet it'll provide full web functionality on 90% of sites. And for the remaining 10%, just switch Turbo mode 'off' in Settings and you're done.
Opera Mini's strength is not so much its speed, though it is very fast too, but its frugal use of data. So, for example, Engadget's bloated hompage comes down from 3MB to around 350k, almost a ten to one reduction in byte count. When you're on a daily or monthly data cap, that sort of reduction can make all the difference, and yet there's no real impact on site content. It's also worth noting that you can install Opera Mobile and Opera Mini side by side and simply use whichever one seems the best fit for your circumstances and needs at the time. And, yes, they're both free, and both support Opera's bookmark syncing system and multiple tabs/windows.
In fairness to Nokia, they're well aware that Web is falling behind and a brand new browser with latest engines is due in the next couple of months. And it's also worth noting that Web supports multitouch for zooming in and out, something which has yet to make it to Opera Mobile.
The next question is how the best of Symbian browsing (Opera Mobile 10.1) compares to the best of the competition. To keep the playing field totally level, I'll assume that Turbo is turned off, but you should bear in mind that this is something of an ace in Opera Mobile's hand, ready to be played if needed. Looking at both the benchmarks and real world loading times, Safari on the iPhone 4 and Browser on the Desire HD, with its faster processor, are understandably a little ahead, but we're only talking a factor of 50% or so, so Opera Mobile 10.1 is probably about as fast as we can go on Symbian right now - it seems almost as well coded as Safari and the Android 2.2 Browser in terms of handing control to the user and I can't recommend it highly enough.
I've gone through a pretty long list of caveats and notes above, but it should also be borne in mind that the bandwidth available to your mobile device, when away from Wi-fi, is one of the biggest factors of all. Stray from 3.5G into vanilla 3G and then into EDGE and GPRS territory and most of the stats and notes above go right out the window. If you are stranded somewhere with less than perfect connectivity then run, don't walk to Opera Mini - its bandwidth savings essentially equal speed.
Starting with the question: "is the current Symbian browser as bad as it's made out?", I'd now answer it as "No, but it could be a lot faster and more responsive. I suggest switching to Opera Mobile until such time as Nokia's new browser appears. And keep Opera Mini installed for emergencies!"
Steve Litchfield, All About Symbian, 25 November 2010