Mobile Browser Cache Limits, Revisited
By Ryan GroveJuly 12th, 2010
In Mobile Browser Cache Limits: Android, iOS, and webOS, I shared the results of my attempts to determine browser cache limits on Android, iOS, and webOS devices. At the end of the article, I wrote:
Use these results as a starting point, but verify them yourself before you make major decisions based on assumptions about mobile cache limitations. The mobile browser world changes at a lightning pace, so this research will have a very short shelf life.
As it turns out, that was good advice: the day after the article was posted, Steve Souders commented that he had run tests using a different methodology that was more representative of a real-world web workflow and had gotten different results.
New Methodology
My original methodology involved navigating directly to a randomly generated page of a certain size, served with a text/html content type. The results using this methodology were reliably reproducible (except on webOS), but as Steve pointed out, users don’t navigate directly to CSS and JavaScript files. My assumption that the limits for direct navigation to an HTML resource were the same as the limits for external CSS and JavaScript was incorrect, so even though the results of my tests were valid, they weren’t widely applicable.
Over the course of many IM sessions, several emails, and a couple of phone calls, Steve and I worked out a new testing methodology. I implemented a version of it on top of my cache testing framework, then Steve implemented a version capable of publishing results to Browserscope.
In the new tests, we load an HTML page that refers to a randomly-generated CSS or JavaScript component of a certain size. Then we navigate to a second HTML page that loads the same component and checks whether or not it was loaded from the cache. To determine whether a component was loaded from the cache, we store a timestamp in a cookie on each request; if the timestamp is updated the second time we load the component, we know the request hit the server, which means the component was not loaded from the cache.
New Results
We found that all the mobile browsers we tested had significantly higher cache limits for external resources loaded by a page than they did for an HTML page itself. This is excellent news for mobile web developers.
The table below illustrates our findings:
| Browser/OS/Device | Single Component Limit | Survives Power Cycle |
|---|---|---|
| Android 2.2 (Nexus One) | 2MB | Yes |
| Mobile Safari, iOS 3.1.3 (1st-gen iPhone) | 4MB+ | No |
| Mobile Safari, iOS 3.2 (iPad) | 4MB+ | No |
| Mobile Safari, iOS 4.0 (iPhone 3GS) | 4MB+ | No |
| Mobile Safari, iOS 4.0 (iPhone 4) | 4MB+ | No |
| webOS 1.4.1 (Palm Pre Plus) | ~0.99MB (1,023KB) | Yes |
Note that 4MB was the largest size we tested, and all the iOS devices cached 4MB components. The actual cache limit for those devices may be larger than 4MB. Also, webOS on the Palm Pre Plus gave consistent results in this test, whereas it had some problems in the previous test.
It’s possible that the much lower limits my previous test showed for HTML components on iOS may indicate the use of a RAM cache for those components, while the much higher limits for CSS/JS components in this test may indicate the use of a disk cache, but this is just conjecture. Android, at least, does appear to use a disk cache in both cases, since its cache survives power cycles.
New Recommendations
Based on these new results, coupled with the results from my previous tests, I offer the following updated set of recommendations:
- Use far-future cache expiration headers. This will prevent the browser from having to send a conditional GET request.
- Try to limit HTML pages to 25.6KB or less if you want them to be cached, since the previous tests showed that this limit—imposed by iOS 3.2 on the iPad—was the lowest HTML resource limit of the devices tested.
- Keep CSS and JS components under 1MB. Of course, 1MB is enormous and your components should be much smaller than this, but don’t bother splitting a component into separate requests for the sake of cacheability unless its size approaches 1MB.
- Consider using the HTML5 application cache if it’s important that your components persist in the cache for a long time, or across power cycles.
- Do your own testing. I stressed the importance of this in my previous article and I’ll stress it again here. Use these results as a starting point, but verify them yourself before you make important decisions based on them.
July 12, 2010 at 9:00 am
[...] Update (July 12, 2010): While the results described in this article are accurate for HTML pages, new tests have revealed very different cache limits for CSS and JS resources. The updated results are described in Mobile Browser Cache Limits, Revisited. [...]
July 12, 2010 at 9:08 am
[...] Many thanks to Ryan Grove for working on this caching test – check out his updated post: Mobile Browser Cache Limits, Revisited. And thanks to Lindsey Simon for making Browserscope such a great framework for crowdsourcing [...]
July 12, 2010 at 10:17 pm
[...] Mobile Browser Cache Limits, Revisited – Ryan Grove gives an update on the their previous work on Mobile Browser cache with an updated methodology which yields different results. [...]
July 16, 2010 at 11:02 am
[...] More Opera Mobile 10.1 for S60: W3C gelocation, border-radius & 2D transforms on S60 platform Mobile Browser Cache Limits, Revisited by Ryan Grove Mobile cache file sizes (and other performance tests on mobile devices) by Steve [...]
December 29, 2010 at 10:16 pm
Can you explain more on “Consider using the HTML5
application cache”?
January 12, 2011 at 2:36 pm
[...] next time the video is played, the same pattern repeats. Nothing appears to be cached. Based on previous research into iPhone 4 cache sizes, I would have expect even the 3.8MB video to get cached. What I Expected to [...]
June 8, 2011 at 3:00 am
[...] 2010, the Yahoo User Interface team ran thorough tests on the cache limits of the most-popular mobile devices. They found that the iPad running iOS 3.2 had the lowest limit, only caching elements that were [...]
June 16, 2011 at 5:15 pm
Bandwidth considerations…
Device Supported techs….
June 19, 2011 at 4:10 pm
Hello,
The limit for the css files is for the compressed file that is transferred over the network, or is the size of that file after it gets de-compressed on the mobile client browser?