What Is a Cache?

The word covers several related things. MDN distinguishes two kinds of HTTP cache. A private cache belongs to a single client, usually the browser, and can store responses personalised for that person. A shared cache sits between the client and the server, for example in a CDN or a proxy, and stores responses that can be served to many users.

The rules for HTTP caching are set out in RFC 9111, published in June 2022, which defines caches and the header fields that control them. People who search for "clear cache" usually mean something else: emptying their own browser's cache. In Chrome on a computer, you open the More menu, choose "Delete browsing data", pick a time range and the data to remove, and confirm.

In each response, the server uses the Cache-Control header to say how long it may be stored. max-age sets the number of seconds during which the copy counts as fresh and can be used without asking. With no-cache, the copy is stored but has to be checked with the server before each use. With no-store, it is not stored in any cache. If there is no Cache-Control header, a cache may apply an estimated lifetime, which MDN calls heuristic caching.

When a copy expires, the cache does not have to download it again in full. It can ask the server whether it has changed by sending the ETag value it received in an If-None-Match header. If nothing has changed, the server replies 304 Not Modified with no body, and the cache keeps using its copy.

To store files for a long time without serving old versions, you change their address whenever their content changes, for example by adding a fingerprint to the file name. MDN calls this technique cache busting.

The cache affects the speed users experience. Google says so in Google Account Help: after clearing the cache, some sites load more slowly at first, because content such as images has to be downloaded again.

It also affects crawling. Google's crawlers support HTTP caching with the header pairs ETag and If-None-Match and Last-Modified and If-Modified-Since, and if a response carries both, they use ETag. Google recommends sending both. It also warns that Googlebot caches resources aggressively and may ignore caching headers when rendering, so it can end up using outdated JavaScript or CSS. The fix it recommends is the same fingerprint in the file name.

We measured this for zds.es on 14 October 2026. The HTML pages send no Cache-Control header, and Cloudflare marks them as DYNAMIC, so every visit is answered by the server. The template's JavaScript file carries a fingerprint in its name, is stored for a year with max-age=31536000 and immutable, and is served from Cloudflare's cache. The font files, which have no fingerprint, are stored for four hours. When we requested one again with its ETag, the server replied 304.

• Give static files with a fingerprint in their name a long max-age.
• Use short lifetimes or revalidation for content that changes without changing its address.
• Send ETag and Last-Modified so that browsers and crawlers can revalidate.
• Reserve no-store for responses that must not be stored, such as personal data.
• Check the actual headers of a page and its resources, not just the configuration.
• Purge the CDN cache after changes to files whose address stays the same.

• Believing that no-cache prevents storage. What it prevents is use without checking first.
• Caching files for a year when their name does not change with their content.
• Testing a change in your own browser without clearing the cache and concluding that it did not work.
• Assuming that Googlebot follows the same caching headers when rendering.
• Sending Last-Modified in a date format that does not follow the HTTP standard.