Apple has reacted angrily a report that found Android was faster at downloading and displaying web content.

According to website optimisation company Blaze, which visited 1,000 top company websites and accrued 45,000 page loads in the tests, Android's Chrome was 52% faster than the iPhone's Safari.

“First of all, we found that Android’s browser is faster. Not just a little faster, but a whopping 52% faster,” Blaze said in a posting on its website.

“Android’s Chrome beat iPhone’s Safari by loading 84% of the websites faster, meaning Safari won the race only 16% of the time. While we expected to see one of the browsers come out on top, we didn’t expect this gap.”

The tests compared Safari in iOS 4.3 against the browser on Android 2.3 smartphones.

However, Apple was quick to contest the results, claiming the test didn't reflect the way Safari performed in its native environment on the iPhone.

The Blaze study was conducted with an embedded iPhone web viewer, which was slower than Safari on the iPhone, Apple said.

“Apple regards the tests as flawed because Blaze used its own proprietary application that doesn’t take advantage of Apple Safari browser’s web-performance optimisation,” Apple said in a statement.

“Despite this fundamental testing flaw, they still only found an average of a second difference in loading web pages.”

However, in a mounting war of words, Blaze has defended its tests and raised questions over how much difference running the same tests on an iPhone would have made.

“We stand behind the statement that Android’s embedded browser is faster than iPhone’s,” the company said. “We hope Apple will help us enable those optimisations and repeat the measurement. Until then, for all we know the missing optimisations may not make a big impact.”

http://www.pcpro.co.uk/news/366118/appl ... speed-slur

Despite all the evidence they had towards this conclusion turning out to be, well, useless. I'm perfectly willing to believe a current SOTA Android phone with a dual core processor is faster at processing HTML & associated data than an iPhone 4 but they simply don't have the scientific mandate to say that.


Err... what? For all they know the 'missing optimisations' may make the page render entirely in Kanji or cause the phone to become self-aware, given how slapdash their testing appears to be. Their conclusion was flawed, for provable and straightforward reasons. It's not up to Apple to fix their test for them, it's up to them to do it right. If that means changing their methodology that's their problem, not Apple's. I don't see why apple are somehow duty bound to save these bozos from their own stupidity.

Company uses crappy science to make name for itself, news at 11... Can't see anyone with half a brain wanting to contract them after this anyway mind..

Jon

clicky


Web site Motorola Xoom Apple iPad 2 Apple iPad
CNET.com 5 seconds 6 seconds 12 seconds
CBSNews.com 6 seconds 10 seconds 16 seconds
GiantBomb.com 5 seconds 5 seconds 6 seconds

That's interesting. Whether the site is busy or not shouldn't usually affect the rendering time of the page if you average it over a few runs - after all the browser doesn't hang about once it gets the data. However it does possibly suggest the Xoom's browser copes with partial/delayed page downloads better than the iPad 2's does. That suggests the Xoom's browser - which I assume is standard across Android 3.0? - would be better if you had a very poor net connection, for example when your 3G connection dropped out and it had to fall back to EDGE or GPRS.

I'd rather like to see the full test details on this because I can't come up with an explanation of 'this one renders quicker than this one on a busy site' which, assuming they've tested it properly (i.e. numerous iterations at different times and on different ISPs for example), I really feel technically happy with. Wonder if they'll publish them at some point...

Jon

I think you're taking "busy" to mean something different from what I understood.

I thought they meant "busy" as in lots going on, lots of images, animations, videos etc.

I think maybe you thunk they meant the web server was busy to the point of being overloaded and slow?

Yes. I hadn't considered the alternative use of the word, now you mention it.

Jon