Leverage browser caching
If cached, the document may be fetched from the cache rather than from the source until this time has passed. After that, the cache copy is considered “expired” and invalid, and a new copy must be obtained from the source. Apache
Cache response headers
Cache-Control: max-agespecify the time period during which the browser can use the cached resource without checking to see if a new version is available from the web server.
ETagspecify a characteristic about the resource that the browser checks to determine if the files are the same.
- It’s important to specify one of
Cache-Control: max-age, and one of
ETag; it’s redundant specify both
Cache-Control: max-agebecause it is more widely supported; set it to a minimum of one month, and take care with values up to one year because maybe you’re violating RFC guidelines,
- Set the
Last-Modifieddate to the last time the resource was changed to avoid the browser re-fetching,
- Use fingerprinting to dynamically enable caching and tell the browser when a new version is available in the server,
- Set the
Varyheader correctly for Internet Explorer (or remove it altogether if possible) because Internet Explorer doesn’t cache any resource that are served with this header,
- Avoid URL hash collision in Mozilla Firefox ensuring that your application generates URLs that differ on more than 8-character boundaries,
- Use the
Cache-Control: publicdirective to enable HTTPS caching in Mozilla Firefox even if the other caching headers are explicitly set.
Leverage proxy caching
This technique let us use static resources cached on public web proxy servers, meaning that even first-time users visit our website can benefit from caching once a static resource has been requested by one user through the proxy (that resource is available for all other users whose requests go through that same proxy). We can indicate with
Cache-Control: public header that a resource can be cached by public web proxies in addition to the browser that issued the request with these exceptions:
- Most proxies don’t cache resources with an interrogation character (
?) event if the
Cache-Control: publicheader is present in the response,
- Don’t enable proxy caching for resources that set cookies setting
Cache-Control: privateor serving those resources from a cookie-less domain,
- Some public proxies have bugs that don’t detect the presence of the
Content-Encodingresponse header resulting in compressed versions of CSS/JS files being delivered to client browsers that cannot properly decompress them; then use
Cache-Control: privateto disable proxy caching altogether for these resources, and set the
Vary: Accept-Encodingresponse header to cache two versions of the resource (compressed and uncompressed) so the correct version of the resource is delivered based on the client request header.
In Apache web servers we can use the module
Mod_Expires.c to configure the expiration dates of the web resources taking the Mime-Type of the file and setting it the cache time (specified in years, months, weeks, days, hours, minutes and seconds); this is an example of how would look a real
.htaccess file in a production environment, setting a default expiration time, long cache checking for generally unchangeable resources like a Favicon file, normal cache time for images and short times for CSS/JS files:
Explanation of HTTP caching in the HTTP/1.1 RFC, details on enabling caching in the Apache Caching Guide and the Google’s project Make the Web Faster. Tutorial made with the help of these resources.