X

Android beats iPhone on browser speed--or not

Blaze Software, pitting an iPhone 4 against a Nexus S, concludes Samsung's Android phone is faster at browsing. Apple concludes the test is flawed, and Blaze is re-evaluating.

Stephen Shankland Former Principal Writer
Stephen Shankland worked at CNET from 1998 to 2024 and wrote about processors, digital photography, AI, quantum computing, computer science, materials science, supercomputers, drones, browsers, 3D printing, USB, and new computing technology in general. He has a soft spot in his heart for standards groups and I/O interfaces. His first big scoop was about radioactive cat poop.
Expertise Processors, semiconductors, web browsers, quantum computing, supercomputers, AI, 3D printing, drones, computer science, physics, programming, materials science, USB, UWB, Android, digital photography, science. Credentials
  • Shankland covered the tech industry for more than 25 years and was a science writer for five years before that. He has deep expertise in microprocessors, digital photography, computer hardware and software, internet standards, web technology, and more.
Stephen Shankland
4 min read
Blaze Software found a Samsung Android phone faster at loading Web pages than an iPhone 4. But Apple said test was flawed.
Blaze Software found a Samsung Android phone faster at loading Web pages than an iPhone 4. But Apple said test was flawed. Blaze Software

A Web performance company has concluded that a high-end Android smartphone, Samsung's Nexus S, is faster at Web browsing than an iPhone 4. Apple, though, says the company's methodology has a significant problem.

Blaze Software concluded after loading 45,000 Web pages from Fortune 1000 companies over 3G and Wi-Fi that the Android phone is faster than the iPhone. The test concluded the Nexus S was 52 percent faster on average, beating out the iPhone 84 percent of the time.

Nonsense, said Apple.

"Their testing is flawed. They didn't actually test the Safari browser on the iPhone. 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," said Apple spokeswoman Natalie Kerris. "Despite this fundamental testing flaw, they still only found an average of a second difference in loading Web pages."

The problem arises because of Blaze didn't use Safari, but rather a programming mechanism that's a close relative. The company said it tested the Web sites with a custom application it created using an Apple technology called UIWebView that lets programmers embed Web content into an app. UIWebView, though, doesn't benefit from some improvements that came to the standalone browser, Safari, with iOS 4.3.

Among those benefits are the new Nitro engine for running Web-based JavaScript programs, according to mobile Web programming book author Maximiliano Firtman, and asynchronous loading of Web page elements to keep one item from blocking another, according to Ars Technica. Also in Safari but not UIWebView are some caching techniques.

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.

While it appears that Blaze's methods may not reflect the way most iPhone users surf the Web, they do raise a valid point about UIWebView. Application developers might want to use it to create their own apps that are essentially conveniently packaged Web applications that don't come wrapped up in the Safari user interface. But those apps would run slower.

And third-party browsers such as Skyfire, which by Apple's App Store rules must use Apple's browser engine, also are affected, Firtman said.

Performance of non-Safari browser apps got attention two days ago, a report in The Register raised the possibility that Apple deliberately is exploiting the inferior performance as a way to drive application developers to use Apple's App Store, where the company keeps 30 percent of revenue.

That concern revolves around yet another way to handle Web apps: creating one out of a Web page. It's an action users can take from within Safari, letting them put an icon on the iPhone home screen, but running that application doesn't actually use either regular Safari or UIWebView.

The conspiracy theory seems pretty silly to me. Perhaps if there were no other smartphone operating systems on the market, a company might resort to shenanigans like that, but it looks to me more likely that Apple simply hasn't yet properly wired up the Web apps to iOS 4.3's new browser features. No doubt there are security checks and quality assurance hoops to jump through, but it looks to me like the kind of thing that'll likely happen at some point.

After all, Apple, while certainly a company with its fair share of control issues, must know that a lot of the success of the iPhone has been because of developers. With Android a strong force and Microsoft's Windows Phone 7, Hewlett-Packard's WebOS, Research in Motion's BlackBerry OS, and Samsung's Bada vying to be contenders, developers have plenty of choices for where to devote their time. And while Web applications have some developer appeal by virtue of the fact that they aren't locked to the iPhone the way native apps are, Apple itself is working on standards such as CSS that make Web apps more useful and powerful.

Even when customers snap up your hardware as fast as you can make it, software is crucial, too, and developers hold many of the keys to the kingdom.

Updated 11:08 a.m. PT with updated comment from Blaze Software. Corrected 12:35 p.m. PT to note that the mobile Safari caching techniques don't involve HTML5.