iOS 5 Top 10 Browser Performance Changes

The much-hyped new version of iOS is finally here, and with it comes a new version of its browser. Here at Blaze we’ve been studying this new browser for a while, to learn what performance related changes it introduces.

Now that the release is official, we can finally share our insights (previously prevented by the Apple Developer NDA).

Before we dig into details, note that iOS offers three flavour’s of its browser.

  1. MobileSafari – The standalone browser included with iOS.
  2. Home-Screen Pages – Pages added to the home-screen by the user after browsing them within Safari. These pages are launched as easily as regular apps, and show up as separate applications in the task manager.
  3. UIWebView – The embedded browser component used within different apps. Many popular apps such as Twitter, Facebook & Yelp use UIWebView, and many popular app development platforms, such as PhoneGap are built on top of them.

Each of these is launched in a different context, and has different features enabled. We therefore repeated our tests, where relevant, for each.

Highlights

If you only have a minute to read this blog, here’s a quick comparison table:

Share This: http://www.blaze.io/wp-content/uploads/2011/10/blazechart.png

JavaScript Performance

One of the most common tests for any new browser version is its JavaScript performance. For iOS, there has been much controversy around whether the modern Nitro engine is used in Home Screen Pages and UIWebView, making it an even more important test than usual.

The table below shows the average results of 3 runs of the SunSpider JavaScript Benchmark (v0.9.1) in each environment. The test measures duration, so lower numbers are better. All tests were done on iPhone 4 hardware.

OS/Browser MobileSafari Home Screen Pages UIWebView
iOS 4 4052 10528 10044
iOS 5 3574 4551 12101

 

As you can see, the JavaScript performance of MobileSafari is a little bit better, improving by roughly 10%. This is to be expected, since new browser versions usually improve performance, but the dramatic improvement was already delivered in iOS 4.3 not too long ago.

For Home Screen Pages, it’s clear that the Nitro engine is now being used. JavaScript performance improved dramatically in those apps, though it still lags a bit behind MobileSafari itself. Our guess is that the Nitro engine is indeed used, but some of its optimizations are disabled, presumably for security reasons.

Lastly, in UIWebView JavaScript performance actually declined! We were extremely surprised by this finding, but repeating the test after power cycles and using the Google V8 Benchmark led to the same results (V8 v3 score of 80 on iOS 4.3 vs 65 on iOS 5). We don’t have a good theory as to why this happened. Perhaps the iOS 5 JavaScript Engine was designed to assume newer hardware? Perhaps it was just an oversight? Any theories (or better yet, data) are welcome.

Rendering Performance

A key performance enhancement in iOS 5 is GPU accelerated rendering. The GPU (Graphics Processing Unit) is much faster than the CPU at processing graphics related actions, such as 3D rendering. Many modern browsers allow websites to leverage the GPU through specific CSS and JavaScript actions, such as translate3d.

iOS 4 performs very poorly when running those predefined graphics actions, and Microsoft created a test called “HTML5 Speed Reading” demonstrating how IE 9 Mobile is way faster. In iOS 5, Apple responds with a dramatic improvement, performing 20x better in Microsoft’s test rendering 40 FPS compared to 2 FPS on iOS 4. Windows Phone 7 clocks at about 24 FPS, and Nexus S at 10 FPS.

Here’s a short video showing iOS 4 vs. iOS 5, clearly demonstrating the improvement:

While most websites won’t become 20x faster in iOS 5, some rich HTML5 functionality will go from unusable to working smoothly. For instance, Joe Hewitt’s iScrollability works great on iOS 5, but is far from ideal on iOS 4.

HTTP Pipelining

Another very interesting change in iOS 5 is the introduction of HTTP Pipelining. As we outlined in previous posts, HTTP Pipelining is a great technique to help address the long latency mobile networks suffer from. Android and Opera have been using Pipelining for a while, and now iOS is joining the party.

HTTP Pipelining is enabled for all browser modes (MobileSafari, UIWebView, Home-Screen). Some private API method names indicate determined developers can probably find ways to disable pipelining in their apps if they have reason to do so.

Digging deeper into its behaviour, here are the specifics on how Pipelining is used in iOS 5 (the terms are explained here and here), compared to the other browsers that support it:

Mobile Browsers Server Support Detection Max pipelined requests Max connections per host Pipeline vs. Connection Distribution
iOS 5.0 Per Host - 6 Fill First*
Android Per Connection 3 4 Fill First
Opera Mobile Per Host 11 4 Distribute First
Opera Mini Per Host 4 10 Distribute First
Blackberry - Not Supported -

* Except for the first set of requests per connection. See below.

iOS 5 mixes and matches other browser behaviours, using Opera’s more aggressive detection model and Android’s request distribution model. Blackberry remains the only top browser not to support HTTP Pipelining, at least for now.

One twist iOS 5 introduces is that the first request on every connection is distributed first, and only then the pipe is filled. For example, if a page makes 24 requests to a host (after verifying host support), split over the 6 connections MobileSafari opens, then:

  • Connection 1 will send requests 1, 7, 8 and 9
  • Connection 2 will send requests 2, 10, 11 and 12
  • Connection 3 will send requests 3, 13, 14 and 15
  • Connection 4 will send requests 4, 16, 17 and 18
  • Connection 5 will send requests 5, 19, 20 and 21
  • Connection 6 will send requests 6, 22, 23 and 24

Personally I think the “Distribute-First” model is better, so I’m happy to see that at least the first requests are distributed, even if the latter ones are “Filled-first”.

Parallel Downloads

A large component of browser performance has to do with downloading files in parallel. Put simply, the more files are downloaded in parallel, the better the performance. On this field, iOS 5 brings with it good and bad news.

The good news is the new support for the “async” script attribute. This attribute allows website owners to explicitly mark a script as “async”, and thus keep it from blocking the page loading event or other scripts on the page. Support for async scripts is especially important on mobile networks, as they make it easier to keep 3rd party scripts from delaying the page load.

The bad news is the removed support for downloading CSS files alongside other resources. Just last week we posted a blog about the CSS bottleneck, and discussed how CSS files in the body are downloaded alongside other files in WebKit browsers. iOS 4.3 worked this way, meaning it didn’t wait for the CSS files to complete before downloading the images on a page. In iOS5, the images won’t start getting downloaded until all CSS files are fully downloaded.

You can test both of these properties and more by running BrowserScope’s Network Tests.

Caching

For the most part, caching hasn’t changed in iOS5. Individual files of at least 4 MBs are still cacheable (as tested using Steve Souders’ test), persistent cache is still zero, and memory cache can still reach 100MB at times (using the same tests we used before).

The main changes happened in how Home Screen Pages handle caching. As Souders observed, Home Screen Apps didn’t enjoy any persistent cache in iOS 4. In iOS 5 that is fixed, and these apps do enjoy proper caching, and don’t need to reload resources on load.

In fact, these Home Screen Pages now enjoy a better cache than MobileSafari does. Running the same tests Souders did on the untapped app showed that even after killing the process or restarting the device, the cached data persisted. Repeating the test for other pages showed the same results.

Adding Nitro to Home Screen Pages, as well as giving them a better cache than MobileSafari enjoys, seriously challenges any conspiracy theories claiming Apple is looking to cripple such apps…

UIWebView seems to remain unchanged, offering some memory cache if used with the right settings, but no persistent cache.

HTML5 Web Workers Support


HTML5 introduces a new entity called Web Workers. These workers are side threads used for running time consuming JavaScript actions. Running such actions on a separate thread leaves the main thread free for user interaction and UI, and makes the application more responsive. You can read more about Web Workers here.

The Android Browser supported Web Workers since Android 2.0, but iOS did not support them until now. iOS 5 now added complete support for Web Workers, which is great news for rich applications.

UPDATE: Android removed support for Web Workers in Android 2.2, due to security concerns. You can see the full list of browser support for Web Workers here.

Better localStorage Management

As the use of localStorage grows, the need to clear this data increases. iOS 5 acknowledged that by replacing “Clear Cookies” and “Clear Cache” buttons with a “Clear Cookies and Data” button, which clears cookies, cache and localStorage information.

In addition, under Advanced Settings users can see the amount of data stored for each site, and clear it. However, our testing indicates the size information is still a bit buggy, and often only shows cookie size data, or an inflated localStorage size.

So? Is It Faster?

This post is meant primarily to explain the differences, but obviously we were curious about the bottom line impact it has on performance too. Our initial testing shows iOS 5 loaded pages are 10% faster than iOS 4.3.

These tests were performed using the iOS Simulator (4.3 and 5.0) over simulated 3G network speeds. The measurement was done using the Mobitest technology, and the test set was Top 100 US Websites, as defined by Alexa. Each page was measured 3 times, and both tests were performed overnight.

The average page load time on iOS 5 was 12.6 seconds, compared to 14 seconds on iOS 4.3. The median page load showed a similar gap, going from 10.4 seconds on iOS 4.3 to 8.7 on iOS 5.

These are only preliminary results, and we hope to run more comprehensive tests later on, including tests of the new hardware as well. We will also make iOS 5 available for testing on Mobitest shortly.

Non-Performance Goodies

Beyond these performance related improvements, iOS 5 offers various browser enhancements, such as:

  • Porting Reader from desktop Safari to Mobile, making it easier to read content on cluttered sites
  • Improved Security controls include private browsing or controlling set-cookie permissions.
  • Enhanced HTML5 support, in areas such as Canvas, form inputs and CSS 3.0 functionality

Summary

iOS 5 brings with it an evolved browser, and improves many aspects of the browser. The most impressive enhancement is the GPU enabled rendering acceleration, beating Microsoft in its own test. The most unexpected new feature is the use of HTTP Pipelining – a great move, but clearly an informed decision and not simple evolution.

That said, it’s also slightly disappointing. The regression in UIWebView JavaScript performance and making CSS files block other resources is unexpected, and degraded performance is something we never expect. In addition, all the enhancements feel like simple evolution, but not revolution, and performance enhancements like Navigation Timings or JavaScript detection of the connection types are notable absences.

Still, iOS 5 is a free upgrade, and customers can expect slightly faster browsing and better caching. Website owners have a few more tools to use to accelerate their websites on the iOS platforms. All in all, iOS 5 is good news for mobile web performance.

Posted on October 12th, 2011
  • http://stevesouders.com/ Steve Souders

    Great, thorough post reviewing the performance changes. Thanks, Guypo! I was really happy to see that Browserscope accurately captured the changes in async scripts and blocking stylesheets.

  • Pingback: (lack of) Caching for iPhone Home Screen Apps | High Performance Web Sites

  • Pingback: phonydev.com » Mobile performance advice

  • http://twitter.com/warpdesign_ Nicolas Ramz ♣

    Weird: I’m only getting 4-5fps at the speed reading test with my Omnia 7 / Mango…

    • Anonymous

      The Mango phone was the only one we didn’t actually have, so the stats are based on this video from their presentation: http://www.youtube.com/watch?v=Or3wvF9ts0I&feature=player_embedded

      Some googling indicated people got similar results, so it seems accurate, but it wasn’t a measurement we performed ourselves (unlike the other measurements in the post)

  • http://twitter.com/erikcorry Erik Corry

    V8 Benchmark Suite scores are more useful when you include the benchmark version number.  Probably you used the latest version, but that won’t be as clear when the next version appears and this article is still readable.

    • Anonymous

      Good catch, thanks. I noted the SunSpider version but not the V8 one. We used v3, and the post is updated now.

  • Tien Le

    Android doesn’t have web workers actually… they were disabled due to security concerns.

    • Anonymous

      Thanks, I updated the post to reflect that. 
      It’s interesting how Android removed Web Workers due to “security concerns” while iOS now supports them, while iOS doesn’t use Nitro JS in UIWebView due to “security concerns” while Android supports V8 in its embedded browser… 

  • Pingback: Safari on iOS 5, HTML5 evolution for iPhone and iPad | Mobile Web Programming

  • Theo

    Any experiences with iOS 5 Safari crashes on iPad 1?
    A Javascript app that never crashed before now keeps crashing while working OK on newest version of Safari on Windows, other desktop browsers and Atomic browser on iOS5 iPad.

  • http://twitter.com/Drew_Malcolm drew malcolm

    …so how might i clear the persistent cache on home screen pages?
    Loving the speed boost, but js and css updates have become cumbersome to
    test — preview updates in mobile safari vs the intended display of web
    app / sans-browser chrome

    • Anonymous

      I’d expect Settings->Safari->Clear Cookies and Data to clear it. Doesn’t it? I’d also suggest killing the process from the task manager (double click the home button, press and hold on an app, choose the red mind sign).

      • http://twitter.com/Drew_Malcolm drew malcolm

        Thanks for reply @Guypo:twitter  – no luck with clear data or killing the app. I’m finding the cache is especially sticky with small image files and sprites. JS and CSS updates can be pushed through by opening the app in the mobile safari client, then refreshing (updates then appear in both mobile safari and home screen app on relaunch), but so far I haven’t found a way to purge old versions of images…

        • Stephanie Houghton

          Are there any updates on this at all?!

  • http://www.shunra.com/ Dror Vinkler

    Correct me if I’m wrong, but as far as I can tell CSS files block parallel downloading only for things that are below them. So, if I put my CSS at the top of the body, it would be the same as putting it in the head. But, if I put it at the bottom of the body, nothing gets blocked and all downloads are done in parallel.
    Of course, putting the CSS at the bottom has the side affect of enabling rendering before the CSS is downloaded, so you might get a flash of unstyled content. But that’s a different problem, I guess.

    • Anonymous

      You’re right in saying CSS only blocks resources placed below it in the HTML, but in most browsers (I believe all the iOS browsers), rendering will be blocked until all CSS files are downloaded. So putting the CSS files at the bottom would delay the time the page starts to render considerably.
      Even in browsers that don’t block rendering, seeing unstyled content is usually a deal breaker, as the site would appear “broken” to the user – which is often considered worse than not displaying anything at all.

  • http://twitter.com/morgancheng Morgan Cheng

    I found one problem about Caching of web page launched from Home Screen. If full screen is enabled by adding below to part, it cannot leverage cache.

    The big pain is that even If-Modified-Since is not included in the request header. So the response is always status 200 with full content. And this is for every time launch.

    I don’t know why there is such wired limitation. 

  • Ethan Samuel

    Most 10 regular needful functions are changed which I like that it’s allows HTML5 speed & web support, caching, parallel downloading of CSS & other file system. 

  • Manoj

    Does iOS6 support HTTP Pipelining?