Skip to content

Instantly share code, notes, and snippets.

@dannycallaghan
Created December 5, 2013 09:14
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dannycallaghan/7802389 to your computer and use it in GitHub Desktop.
Save dannycallaghan/7802389 to your computer and use it in GitHub Desktop.
Google Developers - Web Performance Best Practices - Optimise Caching. From https://developers.google.com/speed/docs/best-practices/caching
##### Optimise caching #####
### Leverage Browser Caching ###
- 'Expires' and 'Cache-Control: max-age'
Specify time period browser can use a local copy without checking for a newer version. Strong cache headers - will not issue a GET request until the expiry or max age is reached.
- 'Last-Modified' and 'ETag'
Specify some characteristic that the browser checks to see if the files are the same - 'Last-Modified' is always a date; 'ETag' is any value that uniquely identifies that resource, like version number or hash. Weak cache header - the browser applies a heuristic to determine whether to use a cahce copy or not (each browser uses a different heuristic). Uses a conditional GET though - don't return a full response unless the resource has changed (thus lower latency than full GETS).
"It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag."
## Recommendations ##
# 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 is more widely supported.)"
- "Set the Last-Modified date to the last time the resource was changed. If the Last-Modified date is sufficiently far enough in the past, chances are the browser won't refetch it."
# User fingerprinting to dynamically enable caching
This is the method of changing the URL (file path) somehow each time the resource changes.
# Watch out for the 'Vary' header in IE
IE doesn't cache any resouce with the 'Vary' header, and any fields other than 'Accept-Encoding' and 'User-Agent'. So strip out all other fields in the 'Vary' header or remove the 'Vary' header completely.
# Avoid URLS that cause cache collisions in Firefox
The FF cache hash function can generate collisions on URLS that only differ slighty. So ensure, when using fingerprinting, etc, that your URLS differ enough to avoid this.
# Use 'Cache-control: public' to enable HTTPS caching in Firefox
Normally used to enable caching by proxies, but proxies can't cache anything sent over HTTPS anyway, so it's always safe to set this for HTTPS resources.
### Leverage Proxy Caching ###
The idea is that the browser downloads from a nearby public web proxy server (most notably used by ISPs) instead of a remote origin server. Even first time users benefit, as another user may have hit that site previously. Since these proxies are are likely to be closer than the remote server, reduces network latency. (Can also give you free site hosting as responses from the proxy cache don't draw on your server's bandwidth at all.)
Use the 'Cache-control: public' header to enable this.
## Recommendations ##
# Don't include query strings in the URL for static resources
Most proxies do not cache resources with "?" in the URL, even if 'Cache-control: public' is set.
# Don't enable proxy caching for resources that set cookies
Since the resource is shared amongst users, so are the cookies. Many proxies won't cache resources with cookie headers set anyway, but better to avoid the risk.
# Be aware of proxy caching issues with JS and CSS
Some proxies have a bug where they can't detect the 'Content-Encoding' header. This can mean compressed versions of files (as they all should be) being sent to browsers that can't properly decompress them. To avoid:
- Set 'Cache-control' to private, thus disabling proxy caching. "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' header. Instructs the proxy to cache two versions - a compressed and an uncompressed version. Correct version 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."
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment