Leverage browser caching
1.Set caching headers aggressively for all static resources.
Set Expires to a minimum of one month, and preferably up to one year, in the future. (We prefer Expires over Cache-Control: max-age because it is more widely supported.) Do not set it to more than one year in the future, as that violates the RFC guidelines.
2.Use fingerprinting to dynamically enable caching.
Google Calendar embeds a fingerprint in its filename:calendar/static/fingerprint_key doozer compiled.css,where the fingerprint key is a 128-bit hexadecimal number.
3.Set the Vary header correctly for Internet Explorer.
4.Avoid URLs that cause cache collisions in Firefox.
The Firefox disk cache hash functions can generate collisions for URLs that differ only slightly, namely only on 8-character boundaries. Thus, if you are using fingerprinting or are otherwise programmatically generating file URLs, to maximize cache hit rate, avoid the Firefox hash collision issue by ensuring that your application generates URLs that differ on more than 8-character boundaries.
5.Use the Cache control: public directive to enable HTTPS caching for Firefox.
Leverage proxy caching
You use the Cache-control: public header to indicate that a resource can be cached by public web proxies in addition to the browser that issued the request.
1.Don't include a querystring in the URL for static resources.
2.Be aware of issues with proxy caching of JS and CSS files.
Some public proxies have bugs that do not detect the presence of the Content-Encoding response header. This can result in compressed versions being delivered to client browsers that cannot properly decompress the files. Since these files should always be gzipped by your server, to ensure that the client can correctly read the files, do either of the following:
- Set the the Cache-Control header to private. This disables proxy caching altogether for these resources. If your application is multi-homed around the globe and relies less on proxy caches for user locality, this might be an appropriate setting.
- Set the Vary: Accept-Encoding response header. This instructs the proxies to cache two versions of the resource: one compressed, and one uncompressed. The correct version of the resource is delivered based on the client request header. This is a good choice for applications that are singly homed and depend on public proxies for user locality.