- Caching in HTTP
- Optimizing for mobile
- Using web storage
- The application cache
- Wrapping up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Optimizing for mobile
The browser cache is very important on a desktop computer, but not so much on touch devices.
In iOS 5, the browser cache is limited to 100 MB and does not persist between app launches. That means that if the phone restarts or the browser is killed or crashes, the entire cache is emptied when the browser starts again. Android 2.x’s stock browser (still the most widely installed version by far) has a cache limit of just 5.7 MB, and that isn’t per domain—that’s total (Table 4.1).
Table 4.1. Persistent Cache Size by Browser
|
OS |
Browser |
Max Persistent Size |
|
iOS 4.3 |
Mobile Safari |
0 |
|
iOS 5.1.1 |
Mobile Safari |
0 |
|
iOS 5.1.1 |
Chrome for iOS |
200 MB + |
|
Android 2.2 |
Android Browser |
4 MB |
|
Android 2.3 |
Android Browser |
4 MB |
|
Android 3.0 |
Android Browser |
20 MB |
|
Android 4.0–4.1 |
Chrome for Android |
85 MB |
|
Android 4.0–4.1 |
Android Browser |
85 MB |
|
Android 4.1 |
Firefox Beta |
75 MB |
|
BlackBerry OS 6 |
Browser |
25 MB |
|
BlackBerry OS 7 |
Browser |
85 MB |
* Adapted from research by Guy Podjarny (www.guypo.com)
It’s very important to optimize the cacheability of your site. But the very limited size of the browser caches means that users will very often come to your site with an empty cache, so optimizing for that state should not be neglected.
A good header for a static resource looks something like this:
HTTP/1.1 200 OK Content-Type: image/png Last-Modified: Thu, 29 Mar 2012 23:53:57 GMT Date: Tue, 11 Sep 2012 21:36:44 GMT Expires: Wed, 11 Sep 2013 21:36:44 GMT Cache-Control: public, max-age=31536000
Cache-Control: public makes sure that SSL resources can be cached by proxies. The max-age is one year (in seconds). The Expires date is also a year in the future.
In practice, it’s a good idea to read up on how to configure your particular server so that the headers are correct. If you’re working with separate back-end developers, gently remind them how important these values are.
For the actual content many major sites use cache-control: private to prevent any caching by proxies. For the Birds of California site, the content won’t change that much, so on the server we can set up the cache headers to expire in one hour. We’re using Nginx, so we can do that with the expires directive:
location / {
expires 1h;
}
This results in a header that looks like this, assuming the site was accessed at 05:16:45 PST:
Last-Modified: Thu, 05 Jul 2012 17:15:35 PST Connection: keep-alive Vary: Accept-Encoding Expires: Wed, 14 Nov 2012 06:16:46 PST Cache-Control: max-age=3600
This prevents mobile users from refetching content too much during a browsing session, but ensures that the content is fresh, even for desktop users.
Another important thing to consider is web accelerators like Amazon Silk. Silk is the browser for the Kindle Fire tablets. Unlike a normal browser, Amazon Silk is a browser that lives both on the Kindle Fire and on Amazon servers. According to Amazon, much of the acceleration comes from pipelining and “predictive push,” which means sending static resources to the browser before the browser even requests the resource. In this case Silk acts as a transparent HTTP proxy. A proxy may cache just like the browser, and it follows the same rules. So by sending the correct headers you’re also improving performance for Kindle users.