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.
My original methodology involved navigating directly to a randomly generated page of a certain size, served with a
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.
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.
Based on these new results, coupled with the results from my previous tests, I offer the following updated set of recommendations: