Sorry, Steve: iPhone 50 Percent Slower Than Android on Web
wired.com
wired.com
An argument can certainly be made that UIWebView being crippled is very much a platform negative (I would agree), but the "study" is purporting to represent the speed of browsing in Safari, which is plainly false.
I wouldn't expect the absence of Nitro to dominate the measurement, however. (Edit: Blaze says that 15% of the time taken, on average, was inside of JavaScript execution, so apparently it's both true that it does not dominate and that faster execution would have made a meaningful change.) I still think their methodology is flawed, though, because the webViewDidFinishLoad: callback can be called multiple times in the loading of a single document. It's not clear which one they listened for: the first one? the last one?
http://stackoverflow.com/questions/908367/uiwebview-how-to-i...
Contrast this with the WebView in Android. It's not obvious what callback they would have used in that case, but looking at the documentation they probably would have listened for onPageFinished(), which appears to get called much earlier, because it is only called when the loading of the main frame is completed. (Again, according to the docs I found).
http://developer.android.com/reference/android/webkit/WebVie..., java.lang.String)
In order for their methodology to make any sense, one would have to conduct the measurements based on callbacks that have the same semantics. Do they? It doesn't look like it to me.
"YEAH STEVE! HOW DO YOU LIKE THAT? 1.1 SECONDS FASTER BITCH! UNH!" Complete with pelvic thrusts. It makes me laugh while I close the tab and completely ignore anything that might have been redeemable about the actual article.
Blaze backed away from its conclusion in light of the new data. Chief Technology Officer Guy Podjarny told CNET in a statement: This test leveraged the embedded browser which is the only available option for iPhone applications. Blaze was under the assumption that Apple would apply the same updates to their embedded browser as they would their regular browser. If this is not the case and according to Apple's response, it's certainly possible the embedded browser might produce different results. If Apple decides to apply their optimizations across their embedded browser as well, then we would be more than willing to create a new report with the new performance results.
I regularly see Chrome, Opera, Firefox and recently IE9 boasting the best times in a bunch of dubious benchmarks. Indeed the one that seems to get the most play these days is Sunspider, Apple's own javascript test which you would assume favors them to some degree. Apple's Safari, I don't see so much of. Why would these expectations be reversed in mobile?
The number of "news" outlets picking it up is staggering:
http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzI...
Congrats to them and thanks for the testing service.
I'm thinking these might not be ideally representative of the kinds of sites I actually browse. Why not test some more content-rich sites, or the most popular sites, instead?
The study was done primarily on iPhone 4 and Google Nexus S.
[1]: http://www.wired.com/images_blogs/epicenter/2011/03/Android-...
"We used iPhone 4 for the iPhone measurements, and Google Nexus S for Android 2.3 measurements. For our Android 2.2 measurements we chose the Samsung Galaxy S, since it has almost identical hardware to the Nexus S, making the OS the primary difference."