

Mobile Browser Cache Limits: Android, iOS, and webOS - rgrove
http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

======
modeless
Why do browsers have such ridiculously low default cache limits? Desktop
browsers do the same thing; Firefox's default cache size is 50 MB. That's
0.01% of my available storage. I'd be more than happy to devote a whole 1% of
my storage to speeding up web browsing, which is after all the primary
activity most people perform on a computer these days. That would give a cache
size of ~150 MB on an iPhone and 5 GB on my desktop.

------
stuff4ben
Would love to see the tests re-run on real data that can be gzipped. You
mention that your Sinatra-based tool: _"generates a response consisting of a
requested number of pseudorandom alphanumeric and whitespace bytes."_ Then you
say that _"gzip had no effect on cacheability on any device."_ I believe that
your conclusion that gzip doesn't work is because it's hard to compress random
(or pseudorandom) text.

~~~
rgrove
Actually, the reason is that the browser uncompresses components before
caching them, so compression has no effect on cacheability.

The generated data are actually a series of newline-delimited MD5 hashes of
pseudorandom numbers, which makes them fairly compressible. For example, 32KB
of data gzips down to about 18.9KB, which seems to me like a pretty reasonable
representation of typical web content.

I didn't conclude that gzip "doesn't work", just that it has no effect on
cacheability. Gzip is certainly good for reducing the number of bytes on the
wire, though.

------
jsz0
Worth noting the Dolphin browser on Android can use your SD card for caching.

------
pilif
I might be wrong, but doesn't HTTP require the Expires header to be set a date
less than or equal to one year in the future? If so, the test might have hit
undefined behavior.

~~~
rgrove
It doesn't require it, but it recommends it:

"To mark a response as 'never expires,' an origin server sends an Expires date
approximately one year from the time the response is sent. HTTP/1.1 servers
SHOULD NOT send Expires dates more than one year in the future." --
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>

In practice, far-future expiration headers used by Yahoo!, Google, and others
are often well over a year in the future, and all browsers support this just
fine.

I did do some sanity checks using various dates in the headers, and I saw no
difference between dates of less than a year and dates over a year in the
future. I decided to run the canonical tests using the far-future dates since
that's what the majority of websites use these days.

------
aristus
Nice work, Ryan! Have you checked out browserscope? I keep meaning to write a
few test suites for it.

~~~
rgrove
Thanks! Yes, I'd love to add some cache tests (and more mobile tests in
general) to Browserscope. Looks perfect for it.

