HTTP Caching Explained: Make Repeat Visits Instant

The fastest network request is the one you never make. When a visitor comes back to your site, their browser can reuse files it already downloaded instead of fetching them again. That is HTTP caching, and it is controlled by a few response headers that many projects leave on default settings. Getting them right is one of the cheapest performance wins in web development.

How HTTP caching works

Every response from your server can include instructions about how long it may be stored and reused. Browsers follow these instructions, and so do shared caches such as CDNs and proxies.

A cached response is either fresh, meaning it can be used immediately, or stale, meaning the cache should check with the server first. The rules are defined in the HTTP caching standard, RFC 9111, and summarized clearly in the MDN guide to HTTP caching.

The Cache-Control header

Cache-Control is the main header you will use. These are the directives worth knowing:

• max-age=N: the response stays fresh for N seconds. 31536000 is one year.

• no-cache: the response may be stored, but must be revalidated with the server before every use. Despite the name, it does not mean "do not cache".

• no-store: never store the response at all. Use it for sensitive data such as banking pages.

• public and private: private limits storage to the user's browser, so a CDN will not keep a copy of personal pages.

• immutable: tells supporting browsers the file will never change while fresh, so there is no need to recheck it even on reload.

Revalidation: ETag and 304 Not Modified

When a cached response becomes stale, the browser does not have to download it again from scratch. It can ask the server whether the file has changed.

The server attaches an ETag, a fingerprint of the file version. Next time, the browser sends that value back in an If-None-Match header. If nothing changed, the server replies with 304 Not Modified and an empty body, and the browser reuses its copy. You still pay for a round trip, but you skip the download.

A simple, proven setup

Most sites can follow one pattern, also recommended in web.dev's guide to preventing unnecessary network requests with the HTTP cache:

1. Versioned static files: cache forever

Build tools can add a content hash to file names, such as app.3f9a1c.js. When the code changes, the name changes too, so the old file can safely be cached for a long time.

Cache-Control: public, max-age=31536000, immutable

2. HTML pages: always revalidate

Your HTML points to the latest versioned files, so it must stay current.

Cache-Control: no-cache

With this combination, a deploy takes effect immediately, while repeat visitors still load scripts, styles, and fonts straight from their cache.

Tips and common mistakes

1. Never give long cache times to unversioned files. If style.css is cached for a year without a hash in its name, visitors may see old styles long after you update it.

2. Keep personal data out of shared caches. Use private or no-store for pages with account details, or a CDN might serve one user's page to another.

3. Use stale-while-revalidate for less critical data. This directive lets a cache serve a slightly old response instantly while fetching a fresh one in the background. The web.dev article on stale-while-revalidate explains when it fits.

4. Check your headers in DevTools. Open the Network panel, click a request, and look at the response headers. A "(disk cache)" or "(memory cache)" label means the cache did its job.

5. Remember the Vary header. If a response changes based on a request header, such as language or compression, Vary tells caches to store separate versions.

Version your assets, cache them forever, and keep your HTML fresh.

Keep exploring

Good caching directly improves loading metrics like LCP, which we cover in our plain-language guide to Core Web Vitals. Version numbers matter for releases too, so read our explainer on semantic versioning, or see the software we build at Ryuartistry.