Browser caching

HTML Markup

Serve these with a Cache-Control: no-cache header. This will instruct the browser to cache locally but only after checking with the server that the content hasn’t changed. Note that no-cache does NOT mean "don’t cache", rather it tells the browser to always revalidate when the resource is requested. no-store tells the browser not to cache at all, which isn’t usually desirable.
See Caching best practices for more information.

Set a long max-age eg: Cache-Control: max-age: 31536000 (one year). The max-age directive states the maximum amount of time in seconds that fetched responses are allowed to be used again (from the time when a request is made) and because content on these URLs typically don't change, it is safe to cache them for really long periods.
Use a cache-busting mechanism for versioning assets to ensure that the browser caches each version as a different URL. Example: sncss-29d48c7.css or sncss.js?v=29d48c7 where “29d48c7” is an auto-generated number unique to every version of the file. Frameworks like Shunter use the filename version style which is preferred.

If it is under your control, ensure the server provides an Entity Tag (ETag) header. The ETag header is an additional identifier for a specific version of a resource, typically comprised of the modified time and file size. (On older systems the ETag may also include an inode portion, but this is problematic.) The Etag header is especially useful to prevent simultaneous updates overwriting each other. If you use a CDN, it is likely this header will already be provided and properly configured. Learn more:
- MDN ETag
- Express options for 'ETag' setting
You no longer need to use Expires headers as it has been superseded by Cache-Control header with max-age, which is supported by modern browsers.

It’s important to note that there isn’t a one-size-fits-all approach to caching, so always decide a caching strategy based on your needs.