Not Cacheableįor assets that are dynamically generated, that are unique or that are only valid once. There are generally four types of caching behaviour we may want a browser to use when it has downloaded a static asset: 1. But then you might as well rename the file to break the cache on the front-end. If you have your own versioning implemented on the web server you could generate ETags yourself. The default is to use the last-modified time and the file size, but you can also choose to use a file digest, and manually include the INode back into the calculation. (See RFC 7232 for more info!)īy default, Apache 2.3.14 and earlier included INode in the ETag - meaning that the ETag for an identical asset would change between servers! This is no longer included by default, and you can configure what is used to produce the ETag in Apache. metadata has been updated but the content is the same), whereas strong ETags should change whenever the asset is changed in any way. Weak ETags (prefixed with W/) should match assets which are semantically the same (e.g.
![shared cache vs private cache shared cache vs private cache](https://service.vsc.ac.at/slides/introduction-to-vsc/01_supercomputers_for_beginners/pictures/vsc3-node.png)
Note that validation of weak ETags (prefixed by W/ in the header) are unsupported in some scenarios - including if using Akamai as a CDN - so you may want to use strong ETags where possible.ĮTags are simply strings which identify a specific version of an asset. The server must also understand conditional get requests and respond with a 304 Not Modified in the case that the cached asset matches that on origin. I also recommend to not emit a Last-Modified header and use ETag instead for asset revalidation, this avoids edge cases such as newer files with identical content or clock mismatches between web servers which would cause unnecessary bandwidth consumption.įor revalidation (aka conditional requests) to work, responses must be served with one or both of the ETag or Last-Modified headers. In general I recommend to not emit an Expires header and rely instead on the more comprehensive Cache-Control header. Pragma - a hangover from HTTP/1.0, this should generally not be used in preference for Cache-Control except where HTTP/1.0 clients must be supported ( docs) Last-Modified - a timestamp which allows browsers to validate the freshness of cached assets ( docs) Some are more obvious than others!Įxpires - a date (in GMT) after which this asset may no longer be used from the browsers cache and must be re-fetched ( docs)Ĭache-Control - a combination of features in one header, including how long the resource can be cached by the client (in seconds) as well as whether proxies can cache it, whether to force revalidation and more ( docs)ĮTag - a string that uniquely identifies an asset version, generally a server-generated hash of the file ( docs) There are a number of response headers set by a web server or CDN which manage client-side caching. A summary of the logic to determine which caching headers are best in different scenarios. or ?v=123) and set a single caching header allowing the maximum cache duration of one year:ĭo not emit unnecessary caching headers (including ETag and Last-Modified) to prevent unexpected client and server behaviours. Use versioned assets wherever possible (e.g. Caching in proxies, load balancers and Content Delivery Networks (CDNs) adds some more complexity, and is not covered here. Note that the focus of this post is on client-side (or downstream) caching - in the client device.
![shared cache vs private cache shared cache vs private cache](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https:%2F%2Fblog.kakaocdn.net%2Fdn%2FtsGpg%2FbtqVIKItEMp%2FfeXo2zOFPhC0sNepdKu7mk%2Fimg.png)
![shared cache vs private cache shared cache vs private cache](http://www.extremetech.com/wp-content/uploads/2014/09/Haswell-Labeled.jpg)
We’ll also talk about invalidating caches and ensuring browsers use the correct assets at the correct time. In this post we will review what caching headers are available and when they should be used. Allowing a browser to use a cached asset can be considered risky - JS which falls out of sync with HTML, CSS which persists an old campaign style, personalised assets accidentally being shared between visitors. The reason that these headers are often misconfigured, or at least configured suboptimally, is often through a descent to lowest risk. The fastest request is the one that is not made, and caching headers allow us to tell browsers when they can reuse an asset that they have already downloaded. Caching headers are one of those deceptively complex web technologies which are so often overlooked or misconfigured.