Apple: iPhone vs. Android browser speed test significantly flawed

“Apple is disputing the findings of independent trials that determined smartphones running Google’s Android mobile operating system load web pages faster than the iPhone, citing significant flaws with the methodology behind the test,” Jason Ankeny reports for FierceMobileContent. “After analyzing 45,000 measurements on the latest Android and iPhone devices, web optimization services provider Blaze Software reported this week that the Android browser loaded web pages 52 percent faster than its iPhone counterpart; not true, Apple claims.”

“‘[Blaze Software’s] testing is flawed. They didn’t actually test the Safari browser on the iPhone,” an Apple spokesperson tells CNet. “Instead they only tested their own proprietary app, which uses an embedded web viewer that doesn’t actually take advantage of Safari’s web performance optimizations. Despite this fundamental testing flaw, they still only found an average of a second difference in loading web pages,'” Ankeny reports.

Full article here.

Stephen Shankland reports for 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.'”

Read more in the full article here.

Related article:
Flawed study claims Android ‘faster’ than iPhone; fails to use actual mobile browsers – March 17, 2011

19 Comments

  1. “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.”

    Either that, or someone teaches us how to use a stopwatch… OR we realize that second differences in a process that takes two seconds to complete is inconsequential.

  2. Anyone else think this is blatant self promotion from this “analytics” company? Didn’t the company know beforehand that UIWebView and Safari produced different results? If so, and they published them anyway; if not, why would anyone now — because of the media circus — want to use them now?

    This whole “story” reminds me of the sort of tactic typical of an antivirus company would use, impinge the Mac platform to promote themselves and sell their product.

  3. If you take a look at their testing methodology the methods used are FAR more flawed than mentioned by Apple. Totally wrong assumptions are made (not just about the embedded browser), terms are wrongly used and abused, inaccurate and invalid methods are used to evaluate the load time of pages and as far as their use of statistics go, its worse than a joke. If some 14 year old kid put this standard of work forward as a project they would get an ‘F’.

  4. the bigger question is why Apple didn’t have both browsers on par with each other. I don’t think it would have been an unfair expectation to have both mobile safari and the embedded webui framework to share the same code. If nothing else, this exposes how sneaky Apple was being, trying to cripple web apps that can compete with native apps on the web store. Time for them to hurry up and get 4.3.1 out with a “fix” for something that should never have been crippled in the first place.

  5. I’m just glad Apple took a proactive stand this time, coming out and challenging these FUDy claims. Obviously Apple cannot be taking on every FUDer out there – in fact, that would just give them credibility they hardly deserve – but sometimes, as in this case, it is good for the company to come out and take the shorts off a FUD merchant.

  6. Blaze insists that Apple needs to change the embedded browser to perform a new test. But Blaze could just get an iPhone4, boot up Safari and perform the test.

    Blaze is unwilling to do that. Instead, it invites Apple to reengineer iOS to maximize the speed of its (Blaze’s) proprietary app — and then it offers to conduct another round of tests.

    All of this reveals that the tests Blaze conducted were actually designed to test the speed of their proprietary app on various phones. They aren’t interested in the raw browsing speed of the phones, and never were.

    The Blaze news release belongs in the ‘software review’ section rather than running as a headline story.

  7. zdnet (not always the biggest fans of apple) had an article on the blaze test: “Android/iweb browsing speed test flawed”.

    When the bloggist KIngsley-Hughes used the Blaze website test app he found this: ” I carried out several runs, and what I found was that I got wildly different results, ranging from under 3 seconds to over 7 seconds … with the wildly fluctuating results I was getting for one site, I’m going to say that all data puled from this test should be treated as speculative and for entertainment purposes only.”

    blaze … azz klowns.

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.