Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Android Cellphones Google Handhelds IOS Apple

Nexus S Beats iPhone 4 In 'Real World' Web Browsing Tests 260

bongey writes "In a series of measured real-world web load tests, the Android-based Nexus S phone spanked the iPhone 4. The Android phone and iPhone 4 median load times were 2.144s and 3.254s respectively. The sample size was 45,000 page loads, across 1000 web sites. It also follows rumors that Apple is intentionally slowing down web apps to make their native apps more favorable."
This discussion has been archived. No new comments can be posted.

Nexus S Beats iPhone 4 In 'Real World' Web Browsing Tests

Comments Filter:
  • Or... (Score:5, Funny)

    by The Grim Reefer2 ( 1195989 ) on Thursday March 17, 2011 @02:11PM (#35520610)

    Maybe they weren't holding the iPhone correctly.

    • by ackthpt ( 218170 )

      Maybe they weren't holding the iPhone correctly.

      The correct holding method is to be standing in queue at the Returns counter.

      • Maybe they weren't holding the iPhone correctly.

        The correct holding method is to be standing in queue at the Returns counter.

        I would have thought that the Apple-approved holding method is to be standing in the queue to purchase the next iteration.

  • Bogus (Score:5, Interesting)

    by Anonymous Coward on Thursday March 17, 2011 @02:13PM (#35520646)

    They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.

    • THIS. Bad test is bad. If you want a good measure of performance, use the native browser on each as that's what the vast majority of users are going to use.
      • by AK Marc ( 707885 )
        What if, the built-in version proxies requests and doesn't actually serve what you ask for? How do you know what's happening in the browser?

        The only reasonable solution to that is to load up an independent app optimized for each of the two platforms. Otherwise, how do you know what the browsers are really doing? If I were building a browser for a phone, I'd do what other mini apps already do and cheat. Not to slow down other apps, like people are hinting Apple may be doing, but to proxy and compress be
        • I highly doubt that anything remotely like this is happening, and for one simple reason: The proxying you describe (I'm assuming you're talking about Skyfire/Opera Mini type server-side compression?) is dog-slow because it increases the ping-time by a ton. My Desire (old 1st-gen Snapdragon device with a decent helping of RAM) loads sites FASTER without any form of server-side caching and/or compression (I've tried this with Opera Mobile, Opera Mini, Skyfire, Miren Browser...), simply because the response ti

    • Re:Bogus (Score:5, Informative)

      by coldfarnorth ( 799174 ) on Thursday March 17, 2011 @02:41PM (#35521108)

      First, read the article written by the folks who did the test: http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/ [blaze.io]

      Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference. Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.

      • Re:Bogus (Score:5, Informative)

        by Anonymous Coward on Thursday March 17, 2011 @03:03PM (#35521392)

        First, read the article written by the folks who did the test: http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/ [blaze.io]

        Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference.

        Nothing in your link supports this. Their update (http://www.blaze.io/business/embeded-browser-vs-native-browser/ [blaze.io]) basically admits that they ran a flawed test, and blames Apple for optimizing its browser.

        Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.

        JavaScript is not the only difference between safari and an embedded web renderer. Safari has different caching and multithreading as well.

      • Re:Bogus (Score:4, Insightful)

        by iluvcapra ( 782887 ) on Thursday March 17, 2011 @03:08PM (#35521484)

        Here, they address this point. First, they compared their app's times with Safari's times, and found no noticeable difference.

        To go to the trouble of testing the thing with their own app, then testing Safari, publishing the numbers for their own app and not publishing the benchmark for Safari seems obtuse in the extreme. Just tell us the numbers you got for the browser.

        Second, they point out that javascript performance accounts for a small fraction of the load times (see large yellow box at the top of the page), and if Nitro was not in use,

        A web browser renders content and loads it as well as executing stuff; javascript is only one part of the whole operation and only pertains to certain use cases.

        they estimate that using it would improve Safari's load times, but would not dramatically change the results.

        Why estimate when they can just run a benchmark on the actual browser, instead of handwaving?

        • Aaaaannnnd in other news, if you read the link I posted, it contains the answers you seek . . .

          One more thing: Is it just me or is your second comment a restatement of what I said in the line above it?

          • Re:Bogus (Score:5, Informative)

            by iluvcapra ( 782887 ) on Thursday March 17, 2011 @04:01PM (#35522334)

            I think you don't understand the problem. The headline is "Android's browser is faster than iPhone's browser," but all they ever tested was:

            The measurement itself was done using the custom apps, which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone.

            UIWebView is not Safari, and neither WebView nor UIWebView are "browsers."

      • Although nowhere near 45,000 tests, Anandtech recently ran a preview of the iPad 2 and did some browsing benchmarks [anandtech.com] to test the CPU where they loaded the pages for the iPad 2, Xoom, and the original iPad. Obviously the two tablets are different animals than the two phones, but given they run essentially the same OS and have beefier CPUs, we should expect similar results.

        However, the iPad 2 is clearly faster in 7 of the 8 tests and the same speed as the Xoom in the remaining 1. It's possible that the webs
      • by node 3 ( 115640 )

        if Nitro was not in use, they estimate that using it would improve Safari's load times, but would not dramatically change the results.

        And that's the best way to run a test. You run a set of well-defined tests and make precise measurements, then you just "estimate" what the real results of a proper test would be...

        There's no way around the fact that this test is flawed. "Estimating" and guessing at the results of a proper test is nonsense. Any Slashdotter who has any respect for scientific methodology should be ashamed to be playing so loose here in order to make their favorite product look better than some other. There's a word for this t

    • Re:Bogus (Score:4, Interesting)

      by molnarcs ( 675885 ) <csabamolnarNO@SPAMgmail.com> on Thursday March 17, 2011 @02:49PM (#35521206) Homepage Journal
      Actually, before buying my NEXUS ONE, I looked up quite a few comparison's on youtube. They were pretty much matched, but it some tests the Nexus was faster. In one particular test, by the time the iPhone4 loaded the homepage of the review sites, on the Nexus it was already loaded and a flash video playing. The difference still was just around 1 second, which is not the end of the world of course, but noticeable enough. I concluded that for web browsing, the Nexus is as good or slightly better as the iPhone. And remember, I'm talking about the Nexus One that came out 4 months before the iPhone4. So I do believe there might be something to this... and yeah, I've been a very happy Nexus owner since then. It's longevity is superb - still can't find anything that tops it. I mean yeah, there are better and faster phones out there right now, but I couldn't find a single compelling feature that would prompt me to buy a new phone for the foreseeable future.
    • They were using a custom app. Not the default browser. So what they are saying is that their app runs faster on the Nexus S. Not that the Nexus S is faster then the iPhone.

      That's a bold assumption AC. How do you know it didn't run slower on the android phones? Have you bench marked each application?

      Still, what do you expect them to do to get accurate results? Use the actual browsers and sit there with a stopwatch?

      How would you approach the problem of getting accurate times?

      Primary Source:
      http://www.blaze.io/uncategorized/mobile/iphone-vs-android-45000-tests-prove-whose-browser-is-faster/ [blaze.io]

      The measurement itself was done using the custom apps, which use the platform’s embe

      • In other words, "Nunh-UNH!"

        • In other words, "Nunh-UNH!"

          Are you referring to my post?. If so, more along the lines of: Why don't you actually look into the methodology and other information as opposed to AC's "Oh yeah! Well your test was stupid!"

          Kinda like this.
          “regards the tests as flawed because Blaze used its own proprietary application that doesn’t take advantage of Apple Safari browser’s Web-performance optimization” - Stated by Natalie Kerris, a spokeswoman Apple.
          source: http://www.blaze.io/business/embeded-browser-vs-native-browser [blaze.io]

          • Consider being a iOS developer wanting to using that engine for your application while competing against a similar application on Android.

            Aren't you moving the goalposts there? First it was 'real world' web browsing on a Nexus S, and now it's load times (and not even that, just the timing of the callback) in a UI widget.

            Still, what do you expect them to do to get accurate results? Use the actual browsers and sit there with a stopwatch?

            I'd expect them to only make comments on things they know about, instead

    • Which given the iPhone and Android use different languages proves nothing. Maybe if they were running the exact same code on both.

      It proves that they can code well for Android but might not be able to code well for iOS?

      Objective C is quite an alien world for the beginner. It's quite a departure from Java and C++ syntactically.

      Also, did they test the battery life? which phone would die first?

      • > Also, did they test the battery life? which phone would die first?

        No. Nor did they test weight, color, specific gravity, reflectivity, touchscreen sensitivity, resistance to solar flares, ability to pass through a bovine's intestinal tract unscathed, nor bullet-proof-ness.

  • When it comes to working efficiently, I've always seen that my Nexus S was better than the iPhones that my friends have. This study is just a more methodological and quantitative observation of what I and other Android users already know.
  • by MrHanky ( 141717 )

    Isn't the iPhone's A4 CPU supposedly some hundred MHz slower than the the one in the Nexus S, giving it better battery life? I don't think this has anything to do with strangling web apps, just different design goals.

    • Hm, trade off 110 msec of my life wasted each time I restart an app vs. 3 days standby time with Wifi and Bluetooth on. Touch choice.

      • Oops meant 1110. That's more serious. Considering it takes me an average of 7865.349 msec to plug in my charger, still a fair trade..

      • Touch choice

        Pun intended? :-)

    • Re:Meh (Score:5, Insightful)

      by SwabTheDeck ( 1030520 ) on Thursday March 17, 2011 @02:27PM (#35520874)

      Isn't the iPhone's A4 CPU supposedly some hundred MHz slower than the the one in the Nexus S, giving it better battery life? I don't think this has anything to do with strangling web apps, just different design goals.

      The iPhone 4 is 777 MHz while the Nexus S is 1 GHz. Both are based on the ARM Corext-A8 and both have 512 MB of RAM. Given the difference in CPU speed, the results of the page load tests don't seem far departed from what would be expected. While the Nexus S is still proportionally a little faster, it isn't so wildly so that it can't be attributed to some minor tweaks in the OS or browser software. Using the term "spanked" seems a bit sensationalist in this instance.

  • by Overzeetop ( 214511 ) on Thursday March 17, 2011 @02:15PM (#35520672) Journal

    Page load speed, that's their metric? And 50% faster is spanked? We're talking about computers, not 100m dash times - I expect an order of magnitude difference. How is the actual browsing experience - how easy is it to read and navigate on a 4" device?

    I will go so far as to quote from TFA:

    "Users don’t always notice the speed gap because websites are sometimes tailored to mobile phones, Blaze said. The difference will become more obvious as users demand richer experiences and move to tablet computers with larger screens.

    So the metric their using to judge the devices isn't very noticeable, and probably won't matter on a device this size ever. Great. Guess if you have to break out a ruler to feel good about yourself...

    • Not to mention that they didn't even use the native browser on each platform, but a custom app, which makes this test even more irrelevant. If you want to measure browser performance, then use the bundled browser that the vast majority of users will be using.
      • Re: (Score:2, Insightful)

        by dgatwood ( 11270 )

        Especially since if last week's story about slower JavaScript performance in apps that embed WebKit is correct, that means there's a good chance that the native browser in iOS would spank the Android browser despite being on a slower CPU.

    • I agree. Unless you are going to run two phones side by side, people will not notice the difference.

      My bigger concern is that Safari on the iPhone makes for a poor user experience (at least compared to Opera on my old Nokia Communicator). Opera did some nice reflowing of HTML elements to fit web pages on a small screen. The iPhone makes the virtual screen size default to 920px across and relies on zooming in and out to be able to read things properly. It is particularly bad when reading text on a page that

      • Now see, I actually like that about the iPhone (and I believe also the default Android) web browser. The way Opera and the default web browser on my Treo both did it was to try to wrap everything to the screen size. It made most sites look awful and poor attempts to wrap around (undersized to the point of near invisibility) graphics often made things hard to read besides. Render the site the way it's meant to be rendered and I'll zoom in and scroll. If I want to look at the graphics I can zoom them triv

        • You would have been using the crappy Opera Mini, which ran on Java. The one on my Nokia was Opera Mobile (I think that was the name) and it was 1000% better than the one you can download from Opera's site as it had a nice mix of a slight zoom and an intelligent reflow that could fit a site in using the same layout that you see on a PC. It helped that the Nokia was a clamshell design that had an internal screen that was 480px wide.

          There was no way of getting the better version except to have it preinstalled

    • HA! the test is used as evidence on how different devices will behave in an imaginary future where everyone demands rich web apps on future tablets. Extrapolating from this that an android tablet would "spank" the ipad is pure speculation. You don't even need the pretense of science to say you think android tablets in the future could be way faster at everything than an ipad. It's possible, but in that hypothetical future, i'll take the slightly slower ipad that lets me hop on it like the silver surfer's su
  • From personal observations, I have noticed that transitions are much smoother on iPhones than on comparable Android phones. For example, if I am browsing photos on an iPhone and I swipe left, I see the image smoothly (60fps or more?) move to the left and the new image smoothly move on. By comparison, every Android phone I have seen implements the same effect, but I see artifacts like tearing or skipping of frames. It looks like it goes at 60fps, then drops down to 5, then back up to 60. I tend to be mor

    • Re: (Score:3, Informative)

      by Digicaf ( 48857 )

      This has a lot to do with hardware acceleration in the GUI, which for the most part isn't there in any Android below 2.3. I bought my Droid 2 last september and noticed exactly what you mention. In 2.3, that's no longer true. It feels MUCH smoother. In fact, my wife went out a month ago and picked up a low end device (with 2.3) that has a much better response rate and feel despite having a processor only half as fast.

      • by Timmmm ( 636430 )

        I'm not convinced by this. The gallery app and the app drawer are both hard-ware accelerated, and neither is as smooth as the iphone. I think it is more to do with the slowness of java/dalvik, and the garbage collector, which only recently became concurrent.

      • >> I bought my Droid 2 last september and noticed exactly what you mention. In 2.3, that's no longer true

        Good to hear. The jerky UI performance on Android is what prevented me from getting an Android phone. Love my iphone4 right now, but it's definitely nice to hear that Android is catching up and I can easily switch in the future if Apple's restrictions start to bother me.

    • Re: (Score:2, Troll)

      by peragrin ( 659227 )

      That's generally it too.

      the IOS UI feels and responds better even under load than android does. think about it, a first generation iphone does smoothly what android needs gigerbread and twice the processor to accomplish.

      Sure the newer phone loads websites better, but the UI is so under performing that it causes all that "saved" time to be wasted again.

      the Ipad(first) and the Xoom is the same way. Sure the Xoom is loads faster at individual tasks, however, the interface lags such that it doesn't seem that

    • A lot of this depends on the phone though - most of the time on my Droid X the transitions are just as smooth as my friends iPhone 4.

    • Depends on the transitions are very smooth in the 3d gallery of stock android, to bad that most phones use their own gallery instead of the 3d one which is absolutely superior to anything else on any platform, the ios gallery is a joke compared to the android one.

  • Apple/Oranges (Score:5, Interesting)

    by beanball75 ( 126064 ) on Thursday March 17, 2011 @02:23PM (#35520816)

    Someone pointed out already that the way they tested is with apps that use the browser engine available to apps. As the second link says in the main story (probably, I'm too lazy to RTFA, I read others already), the iOS browser engine doesn't use the Nitro javascript engine.

    I found one link that discusses it, but I'm sure there are better ones:

    http://www.informationweek.com/news/personal-tech/smart-phones/showArticle.jhtml?articleID=229301178

    • ^^^ This.

      Where are mod points when you need them? The methodology was flawed since they built a custom app, rather than using the actual browser. Admittedly, there is a bug in iOS at the moment, but most people don't access the web that way.

  • That's nice. (Score:5, Insightful)

    by DWMorse ( 1816016 ) on Thursday March 17, 2011 @02:23PM (#35520828) Homepage

    That's nice.

    Now, how quickly does it play Netflix movies? What's it's Hulu Plus app like, does it work nicely?

    You don't say.

    Seriously, for shame. I really do want an Android phone. It just isn't as functional yet. Another year or two of maturity and I think I'll finally get to switch.

    • That's nice.

      Now, how quickly does it play Netflix movies? What's it's Hulu Plus app like, does it work nicely?

      You don't say.

      Seriously, for shame. I really do want an Android phone. It just isn't as functional yet. Another year or two of maturity and I think I'll finally get to switch.

      Netflix? Hulu Plus? You know those are going to pulled from the App Store after June 30th right? Unless they (or you) cough up 30% (or 43%) extra.

      • Hey, right around when my contract is up. Sweet.

        Personally, I think it's a ploy, scare the consumer into being glad that Apple took mercy on them and "looked out for their interests." (Hah.) But, if not, a 32GB iPhone 4 holds value like nobodies business, so I'll recoup the cost of whatever top of the line model is available for an Android handset. If they do indeed pull it. But I'm not ready to believe they'd take such a step backwards until it's actually gone. Then, I voice my opinion with my dollars.

    • That's nice.

      Now, how quickly does it play Netflix movies? What's it's Hulu Plus app like, does it work nicely?

      You don't say.

      Seriously, for shame. I really do want an Android phone. It just isn't as functional yet. Another year or two of maturity and I think I'll finally get to switch.

      Software matters. We keep learning this lesson with video game consoles. For some reason, though, people keep going spec happy with tablets and phones.

  • by Mad Merlin ( 837387 ) on Thursday March 17, 2011 @02:23PM (#35520832) Homepage

    Since the beginning, the iPhone has had busted CSS support for position: fixed; elements, which is terribly unfortunate as it makes Game! [wittyrpg.com] difficult to play. How does the Nexus S fare?

  • That's damn fast. Even my 750k high speed line can't do that.
    Can the Nexus run Opera?

    • by blair1q ( 305137 )

      "750k high speed line"

      Welcome to the future. Is that a real 5.25" floppy disk in your trapper-keeper?

      • Yeah 750k is slower than your 20,000k line, but show me where else I can get a hulu.com-compatible line (for watching Stargate and other shows) for only $15/month. It doesn't exist.

        >>>5 1/4" floppy disk

        Fixed that for you. ;-) And no I upgraded to the new "stiffies" a long time ago.

        • by blair1q ( 305137 )

          Sorry, my brain works in analog and digital simultaneously.

          And I think my local telco now brags about 7 mbps for $19.99. You can do 720p over that. Netflix ahoy.

          But yes, I do have the 30 mbps cable line instead. And the cable company is now my phone company. I wish the satellite company didn't have latency issues. Except for its abysmal web channel guide, DirecTV delivers the goods most days.

    • by Macrat ( 638047 )

      That's damn fast. Even my 750k high speed line can't do that.

      AT&T's blazingly fast "broadband" DSL.

  • Why not also include WP7? Has it been written off before people even try it?
  • Just-released gadget is faster than year-old gadget! You know It's news, because it has something to do with Apple!

    • Sorry, I don't really keep up on phones... looks like it's been out a couple months already.

      Still, it's a bit silly to compare them, since in a few more months we'll be screaming "iPhone 5 beats Nexus S!", then later "Nexus 3 beats iPhone 5!"...

  • by macs4all ( 973270 ) on Thursday March 17, 2011 @02:33PM (#35520986)
    Really, this is pretty much a new low in comment-baiting for Slashdot.

    This so-called "test" is so utterly and completely unscientific as to be not worth the service space it is stored on.

    Period.

    It's supposed to be NEWS for Nerds, and this hardly qualifies. And, not content to troll on its own, the summary has to link to ANOTHER Flamebait summary to "support" its "point".

    Note to Slashdot: You can do better than this; so DO it already!
    • by blair1q ( 305137 )

      Well, no, it can't, because they're using an iPhone to check the submissions for postworthiness, and they just don't have time to make sure they're all good.

    • Oh stop whining. We, as usual, are ignoring both TFA and TFS. We're just happily bouncing our keyboards and gabbing about random things. I'm sure you've noticed that the comments have nothing at all to do with the subject, the article, each other or the laws of Thermodynamics. It's just about Apple and occasionally Microsoft.

      Now go away, or I shall taunt you another time.
  • They got a skeptical view counter point...

    From the article:

    âoeWe know thereâ(TM)s no such thing as a perfect Web page load measurement.â

    My first thought was, why not have a simple page that grabs the current time, loads a page in the iframe, when the iframe triggers it's ready() event, grab the current time and compare against the start for a load time analysis? the overhead of having it in an iframe can't be *that* bad can it?

    • by swb ( 14022 )

      Why not have a workflow measurement? Have groups of people perform a set of standardized actions on a set of standardized web tasks and see which group on average finishes faster?

  • This is just like all those articles that say that BrowserX has a javascript engine that is 15% faster than BrowserY. As an engineer that is a tiny bit interesting (only a tiny bit mind you) but as an end user I could not possibly care less. I honestly cannot feel the difference even if it is measurable. Benchmarks hold little fascination for me and are almost always irrelevant to my choice of device. A 2 second versus a 3 second load time? Sure there is a difference but not enough for me to really not

  • Why is that every time you show some Android product has better feature or performance, call it X, than an competing Apple product the reply from Apple fans follows this logic..

    People don't care about X

    Eventually Apples popularity will start to fade and people WILL care.
    1 second difference can add up to a lot of time if you read many web pages, or you are searching for something. Just do the math. Say 100 modest amount web pages a day , 365 days a year. So you have (100*365)/3600 = 10.13 extra hours spent a year staring at scre

    • by Dunega ( 901960 )
      Oh please, if you're so concerned over how much time you've wasted waiting for all of those 1 seconds maybe you should have done the browsing on an actual desktop or laptop computer. Stop making a mountain out of a mole hill.
  • Well... no. (Score:5, Informative)

    by joh ( 27088 ) on Thursday March 17, 2011 @03:05PM (#35521434)

    First, Apple isn't "intentionally slowing down web apps to make their native apps more favorable." They have added a new JS interpreter (actually a just-in-time JS compiler) to Safari, but not to the "normal" web views that other apps can embed. This means only Safari is faster now, others are as fast as before.

    Second, this test is flawed since it does not use Safari. It uses a custom app which uses neither the new JS engine nor the better caching of Safari or asynchronous multithreading.

  • They show that they can beat the iPhone in one discipline (browser speed) with some cheating (custom app, not the default browser). Well, that's not the trick. You have to beat the complete package to be the better phone.

  • Holy crap, stop the presses. It's a freaking second, not a big deal.
  • I didn't notice any difference, but who am I other than an average person who does average things on smart phones that don't appear to be any faster than each other...to me
  • by milkmage ( 795746 ) on Thursday March 17, 2011 @05:40PM (#35523588)

    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: http://news.cnet.com/8301-30685_3-20044325-264.html#ixzz1GtaYoees [cnet.com]

Garbage In -- Gospel Out.

Working...