4 ms·

Mobile Browser Cache Limits: Android, iOS, and webOS

24 points by rgrove 16y ago

jsz0 16y ago
Worth noting the Dolphin browser on Android can use your SD card for caching.
pilif 16y ago
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 16y ago
  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 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.
stuff4ben 16y ago
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 16y ago
  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.
modeless 16y ago
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.
aristus 16y ago
Nice work, Ryan! Have you checked out browserscope? I keep meaning to write a few test suites for it.
- rgrove 16y ago
  Thanks! Yes, I'd love to add some cache tests (and more mobile tests in general) to Browserscope. Looks perfect for it.

24 points by rgrove 16y ago

jsz0 16y ago

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

pilif 16y ago

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 16y ago
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 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.

stuff4ben 16y ago

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 16y ago
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.

modeless 16y ago

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.

aristus 16y ago

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

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