
Sorry, Steve: iPhone 50 Percent Slower Than Android on Web - bkudria
http://www.wired.com/epicenter/2011/03/android-iphone-web/
======
bbatsell
They 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
Isn't Nitro a Javascript engine? Why will it affect page load times?

~~~
pohl
That 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-i...](http://stackoverflow.com/questions/908367/uiwebview-how-to-identify-
the-last-webviewdidfinishload-message)

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...](http://developer.android.com/reference/android/webkit/WebViewClient.html#onPageFinished\(android.webkit.WebView),
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.

------
mikerhoads
I 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
I 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.

~~~
alexqgb
I believe the word you're looking for is "crotchchop"
[http://www.fortunecity.com/olympia/mcmahon/48/multimedia/dxc...](http://www.fortunecity.com/olympia/mcmahon/48/multimedia/dxcrotchchop.jpg)

~~~
Skroob
And if you're not down with that...

------
37prime
From 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>

~~~
jedsmith
Not sure why you got downvoted -- it's an important point, and was brought up
elsewhere in this discussion.

~~~
tvon
Because that tiny downvote arrow is right below that tiny upvote arrow, and
you can't change your vote...

------
ZeroGravitas
There 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
This 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-i7ZmzI...](http://news.google.com/news/more?ncl=du8BOOH4hczn4YMB-i7ZmzIl2NHpM)

Congrats to them and thanks for the testing service.

------
Bud
I 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?

------
prestia
Follow up post on why the study was flawed:
[http://www.loopinsight.com/2011/03/17/study-comparing-
androi...](http://www.loopinsight.com/2011/03/17/study-comparing-android-to-
iphone-web-browsing-speed-flawed/#)

------
mangirdas
I love open source approach of Android. Also I love IPhone design.

~~~
th0ma5
This 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.

------
bkaid
Article 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?

~~~
jedsmith
The 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-...](http://www.wired.com/images_blogs/epicenter/2011/03/Android-
vs-iPhone-F1000-Paper.pdf)

~~~
mbrubeck
The "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
I missed the "detailed methodology" near the end. Thanks for pointing that
out.

