7 ms·
Sorry, Steve: iPhone 50 Percent Slower Than Android on Web
- bkaid 16y agoArticle cleary states which Android phone was used in the test but doesnt state which iPhone was used. It just says iphone 4.2 and iphone 4.3. Does that mean a iphone 3g on 4.2 and a 3gs on ios 4.3?
- blinkingled 16y agoArs says it was iPhone 4 running iOS 4.3 - http://arstechnica.com/gadgets/news/2011/03/nexus-s-beats-iphone-in-real-world-web-tests-says-firm.ars http://arstechnica.com/gadgets/news/2011/03/nexus-s-beats-ip...
- jedsmith 16y agoThe paper itself[1] says: The study was done primarily on iPhone 4 and Google Nexus S. [1]: http://www.wired.com/images_blogs/epicenter/2011/03/Android-vs-iPhone-F1000-Paper.pdf http://www.wired.com/images_blogs/epicenter/2011/03/Android-...
- mbrubeck 16y agoThe "primarily" refers to the fact that they used a different Samsung phone for their Android 2.2 measurements. Android 2.2 is not available for the Nexus S, so they used the Galaxy S which is based on the same processor/chipset.
- jedsmith 16y agoI missed the "detailed methodology" near the end. Thanks for pointing that out.
- 51Cards 16y agoFrom the paper itself: "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."
- mangirdas 16y agoI love open source approach of Android. Also I love IPhone design.
- th0ma5 16y agoThis is key, and arguably makes these kinds of discussions to be comparing apples and oranges. iPhone champions design aesthetic and top-down control, whereas Android champions OEM flexibility and a more open and multi-vendor compatibility. So Apple is not scrutinized enough, in my opinion, for the control being the only reason they can pull off their aesthetic. When you are trying to get multiple companies and technologies all working together, a lot more compromise has to be made for sure.
- mikerhoads 16y agoI know it is the Internet and I should be used to it now but when the first two words of the title are there purely as snark to rile up fan boys, I really lose interest in the article.
- Skroob 16y agoI keep imagining it like the writer prints out the article and then holds it up right in Steve Jobs' face, and then taunts him like he just won the Super Bowl. "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.
- bbatsell 16y agoThey didn't use Safari, they used a custom-written app with an instance of UIWebView. For a variety of (purportedly security-related) reasons, UIWebView has always been slower than Safari, but it's especially pronounced in iOS 4.3, where UIWebView didn't receive any of the Nitro upgrades that Safari did. 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.
- recoiledsnake 16y agoIsn't Nitro a Javascript engine? Why will it affect page load times?
- pohl 16y agoThat depends upon how they measured. From reading their methodology, it sounds like they may have ended their measurement when they got a "document complete" callback (in their nomenclature). That sounds as if they were listening for the UIWebViewDelegate's webViewDidFinishLoad: method. If the initial page load triggers some javascript at page load time to dynamically create elements in the DOM or do any other setup work, that could easily been within the scope of their measurement. Depending on what the Fortune 1000 websites look like, of course. 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-identify-the-last-webviewdidfinishload-message 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/WebViewClient.html#onPageFinished(android.webkit.WebView 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.
- deleted 16y ago[deleted]
- Bud 16y agoI also noticed that the test sites were the sites of all the Fortune 1000 companies. 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?
- 37prime 16y agoFrom CNET: 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. http://news.cnet.com/8301-30685_3-20044325-264.html http://news.cnet.com/8301-30685_3-20044325-264.html
- prestia 16y agoFollow up post on why the study was flawed: http://www.loopinsight.com/2011/03/17/study-comparing-android-to-iphone-web-browsing-speed-flawed/# http://www.loopinsight.com/2011/03/17/study-comparing-androi...
- deleted 16y ago[deleted]
- ZeroGravitas 16y agoThere seems to be some surprise across the web at this result. Putting aside whether it is a valid result due to UIWebView bugs or the fact that the iPhone processor is clocked lower etc., I would have thought most people would have assumed a browser made by Google would be faster than a browser made by Apple. Google seemed to ignite, and often lead this browser speed competition that makes headlines so often these days. 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?
- ck2 16y agoThis was an extremely clever study/press-release from Blaze. The number of "news" outlets picking it up is staggering: http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzIl2NHpM http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzI... Congrats to them and thanks for the testing service.