Performance Research, Part 5: iPhone Cacheability – Making it Stick

By Tenni TheurerFebruary 6th, 2008

This article, co-written by Wayne Shea, is the fifth in a series of articles describing experiments conducted to learn more about optimizing web page performance (Part 1, Part 2, Part 3, Part 4). You may be wondering why you’re reading a performance article on the YUI Blog. It turns out that most of web page performance is affected by front-end engineering, that is, the user interface design and development.

At MacWorld 2008, Steve Jobs announced that Apple sold 4 million iPhones to date, that’s 20,000 iPhones sold every day. Net Applications reports that total web browsing on iPhone is up at 0.12% for December 2007, topping the web browsing on all Windows Mobile devices combined. Apple’s iPhone has changed the game for many users browsing the web on a mobile device. Web developers can now create functionally rich and visually appealing applications that run within the iPhone’s version of the Safari Mobile web browser. While the iPhone presents new and exciting opportunities for mobile web application developers, it also provides a unique set of performance challenges.

Limited information is available on this device and understanding the cache properties of the browser is essential to creating a high performance web site. In earlier posts, we described how 80% or more of the end-user response time is spent on the front-end, and why the cache matters. In this research, Yahoo!’s Exceptional Performance team investigated the iPhone cache properties and looked at how the performance rules are affected. We were particularly interested in the following cache properties on the iPhone:

  • The maximum cache limit for an individual component.
  • The maximum cache limit for multiple components.
  • The effect of gzipped components on the maximum cache limits.
  • Whether cached components are persistent between power cycles.

We conducted our cache experiments with both Apple’s iPhone and iPod Touch, and came to the same conclusions.

Cache Hit or Miss?

In Part 2, we discussed the importance to differentiate between end user experiences for an empty versus a primed cache page view.

When an external component (scripts, stylesheets, and images) is referenced in an HTML page, the browser makes an HTTP request and stores the component in memory while the HTML page is rendered. Though components are stored in the browser’s memory during rendering, they may or may not be stored in the browser’s cache. A “cache miss” refers to when the browser bypasses the cache and requests the component over the network. A “cache hit” refers to when the component is found in the cache and the corresponding HTTP requests are avoided.

Components are cacheable when they include either the expires or cache-control header.

      Expires: [Expiration time in GMT Format]
      Cache-Control: max-age=[Expiration time in seconds]

Components that do not have one of the above headers will not be cached by the browser. To discover the cache capabilities on the iPhone browser and get a cache hit, we configured the server to include the following response header:

      Expires: Thu, 15 Apr 2010 20:00:00 GMT

Maximum Cache Limits

In our experiments, we varied the size of different types of components (images, stylesheets, and scripts) to determine the maximum cache size for an individual component. We found that if the size of component is greater than 25 KB, the iPhone’s browser does not cache the component. Thus, web pages designed specifically for the iPhone should reduce the size of each component to 25 Kbytes or less for optimal caching behavior.

The good news is if the browser downloads a component larger than 25 KB, components already in the browser cache are not affected. Components already in the cache are only replaced by newer cacheable components under 25 KB using the LRU (least recently used) algorithm.

Apple’s website indicates a 10 MB limit for individual components. The limit applies to the browser ability to store component in memory (not disk). However, the actual size that the iPhone can handle is much smaller, and depends on memory fragmentation and other applications that may be running concurrently. The uncached components are reclaimed by the browser when the page unloads.

To determine the maximum limit of the iPhone cache for multiple components, we incremented the number of 25 KB sized components embedded in our page. We tested the various component types and found that the iPhone browser was able to cache a maximum of 19 external 25KB components. The maximum cache limit for multiple components is found to be 475K – 500 KB.

Compressed Components

We also analyzed the impact of the cache characteristics on components transmitted with and without compression. We were surprised to find that the 25 KB maximum cache limit for a component is independent to whether the component was sent gzipped. The Safari browser on the iPhone decodes the component before saving it to the cache. Therefore, only the uncompressed size matters, which further emphasizes the importance of keeping the size of components small.

The Effect of Power Cycle

Every once in awhile, iPhone and iPod Touch users will need to force a hard reset, or in other words, cut the power and reboot the device. This is achieved by a hold of the sleep button for five seconds, and a simple slide to power off. Suppose a user was browsing your site at the moment before the reset. Will the images and stylesheets still be in the browser’s cache when the user returns to ensure a speedy response time when the user returns? We discovered that the iPhone browser cache is not persisted across power cycle. This means that the Safari browser cache on iPhone allocates memory from the system memory to create cached components but does not save the cached components in persistent storage.

Case Study: Yahoo! Front Page

Yahoo! launched a beta version of the mobile home page at the Consumer Electronics Show (CES) in January 2008. From a performance standpoint, this makes perfect sense. The iPhone has an amazing UI, but it is limited by the small cache size and slow network speed. Downloading large components over the air through the EDGE network is slower compared to DSL. According to published reports, the typical data download speed varies from 82 kbps to 150 kbps. Though the WiFi network speed is usually more acceptable, it’s better to give users the choice in which experience they’d prefer. Let’s take a closer look at the caching characteristics of the mobile and desktop versions of Yahoo!’s Home Page on the iPhone. Figure 1 below shows a comparison between the two.

Figure 1. Yahoo! Front Page Mobile and Desktop versions on the iPhone

Yahoo! Front Page Mobile and Desktop versions on the iPhone

The desktop version of Yahoo!’s home page is roughly 11 times heavier in total size than the mobile version. As a result, the response time to load the desktop version on the iPhone is over 10 times as long. Table 1 shows a summary of the total size and number of HTTP requests to load the Yahoo!’s Front Page mobile version. Loading the page on the iPhone over the EDGE network, it took on average 2.2 seconds to load with an empty cache and on average only 1.5 seconds to load with a primed cache. Table 2 shows the desktop version took on average 25.4 seconds to load with an empty cache and on average 19.9 seconds with a primed cache. That’s 32% faster with a primed cache than empty cache to load the mobile version, rather than only 22% faster to load the desktop version. While the mobile site is designed for optimal caching behavior, the desktop version contains many more components that are uncacheable by the iPhone.

Table 1. iPhone Mobile Experience
Empty Cache Primed Cache
HTML/Text 5K (23K*) 5K (23K*)
Images 14K 5K
Total Size 19K (37K*) 10K (28K*)
HTTP Requests 23 4
Response Time 2.2 sec 1.5 sec
Table 2. iPhone Desktop Experience
Empty Cache Primed Cache
HTML/Text 32K (121K*) 32K (121K*)
Images 117K 32K
JS/CSS 74K (278K*) 73K (272K*)
Total Size 223K (517K*) 137K (425K*)
HTTP Requests 30 4
Response Time 25.4 sec 19.9 sec

* Uncompressed sizes measured in kilobytes.

Takeaways

Design sites specific for iPhone users. In addition to improved usability, you will also reduce the overall page weight and enhance end-user’s performance. Yahoo!’s Exceptional Performance team identified 13 rules for making web pages fast. The iPhone cache experiment suggests an additional performance rule specific for developing web sites for the iPhone:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior.

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 – 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.

20 Comments

  1. You mention up to 19 external objects of 25 KB or smaller may be placed into the Safari for iPhone cache. Why is there then a maximum cache ceiling range extending 25 KB above the sum of these objects (475-500 KB)?

  2. [...] Sill looking for a way to improve your site’s performance after trying other methods? Well Tenni Theurer, a Product Optimization Manager at Yahoo has five great articles that covers reducing the number of HTTP requests, explains web browser caching, the effect of HTTP cookies (co-written by Patty Chi), parallel downloads (co-written by Steve Souders) and details on caching for the iPhone and iPod Touch. [...]

  3. This is great stuff.

    It would also be awesome if you also performed this analysis for something like the Blackberry browser. For some sites, it’s able to take the full version and quickly generate a version of the site optimized for the phone; however, for sites on Y! network, the results are generally pretty horrendous.

    The answer may be to create WAP version for the phone, but there might be ways of generating HTML that renders well and offers users a richer experience. Knowing it’s constraints would be great.

  4. [...] focuses on the full capabilities of the iPhone’s Safari browser including browser cache and transfer spee… It’s an interesting read, for example: The iPhone has an amazing UI, but it is limited by [...]

  5. Hi Niall,

    Regarding your question “Why is there then a maximum cache ceiling range extending 25 KB above the sum of these objects (475-500 KB)?”, note that it is possible for the maximum limit to be anywhere in the 475K to (500K – 1) range for 19 components of size 25KB to be cacheable.

  6. Dave Richards said:
    February 7, 2008 at 3:21 pm

    Since I got my iPhone, I’ve spent a lot of time on wrapping existing websites I use A LOT for my iPhone.

    I got a MASSIVE boost in performance by replacing images with inline canvases instead, especially for animations.

  7. [...] Performance Research, Part 5: iPhone Cacheability – Making it Stick The YUI blog investigates how to optimize web performance for the iPhone. The iPhone’s cache clears at each power cycle, and it will not cache files 25KB or larger. These facts call for special considerations when optimizing for performance. (tags: yahoo! apple iphone mobile [...]

  8. Dave, can you elaborate on “replacing images with inline canvases”?
    Thanks.

  9. [...] case you missed, test show that Safari on the iPhone will only cache objects that are under 25k. Something to keep in mind as you build your iPhone web apps. This entry was written by [...]

  10. [...] a de sérieuses limitations sur le cache. Yahoo! avait déjà débusqué les limites de l’iphone : les fichiers ne doivent pas dépasser 25 ko une fois décompressés et le total doit être [...]

  11. [...] you partner that with Steve Sounders research on iPhone caching. The iPhone cache experiment suggests an additional performance rule specific for developing web [...]

  12. [...] This article is the sixth in a series of YUIBlog articles describing experiments conducted to learn more about optimizing web page performance (Part 1, Part 2, Part 3, Part 4, Part 5). [...]

  13. [...] more information check “Performance Research, Part 5: iPhone Cacheability – Making it Stick“ by Wayne Shea and Tenni [...]

  14. [...] launched, the Yahoo! Exceptional Performance Team (and others outside of Yahoo!) discovered that Mobile Safari doesn’t cache components larger than 25KB pre-gzip. This presents a bit of a problem for iPhone web apps using YUI since the core YUI [...]

  15. [...] There have been some questions of busting the iPhone cache with this technique. As was documented on the YUI Blog the iPhone does not cache items over 25kb pre-gzip. If you’re going to use this technique [...]

  16. Nathar Leichoz said:
    October 14, 2008 at 7:26 am

    Do the 19 components limit apply per-domain or globally?

  17. [...] Freedom to prototype fast: Growing support of iPhone and Palm Pre with toolkits like YUI. [...]

  18. [...] Because every good technical discovery is based on trying to prove someone else wrong, I set out this evening to try and prove that the iPhone cache limits are no longer what this 2008 YUI blog post says. [...]

  19. [...] Theurer and Wayne Shea’s post on the YUI blog “iPhone Cacheability – Making it Stick” makes for some interesting reading. Their research shows an iPhone will not cache components of a [...]