Browser Caching Explained for Website Owners

When someone visits your site for the second time, their browser may already hold copies of your logo, your stylesheet and your scripts. If your server has told it how long those copies can be trusted, the browser can reuse them instead of downloading them again. That is browser caching. Google's web.dev guide puts the benefit simply: a cached response eliminates both the network latency and the data costs of the transfer. This article explains the settings in plain terms, so you can ask your web person the right questions.

How a browser decides to reuse a file

The rules are set out in the HTTP caching standard, RFC 9111. Two ideas do most of the work:

• Fresh or stale. Each stored response has a freshness lifetime set by your server. While it is fresh, the browser can reuse it without asking. Once it is stale, it needs checking.
• Revalidation. To check a stored file, the browser asks the server whether it has changed. If it hasn't, the server replies 304 Not Modified and the browser keeps using its copy. Only that short reply crosses the network, not the whole file again.

Your server communicates all this in a response header called Cache-Control. Depending on your set-up, it may come from your host, your content management system or a content delivery network, so it's worth asking what yours sends.

The four settings worth knowing

• max-age sets how long, in seconds, a response stays fresh. MDN points out that it counts from when the response was generated on the server, not when it arrived. max-age=31536000 is one year.
• immutable tells the browser the file won't be updated while it is fresh. It is defined in RFC 8246, which says clients shouldn't send a revalidation request for a fresh immutable response, even on a normal reload. MDN notes that browsers which don't recognise it should ignore it.
• no-cache is the most misunderstood. It doesn't mean “don't cache”. MDN is explicit: the response can be stored, but must be revalidated with the server before each reuse. If nothing has changed, that means a quick 304 rather than a full download.
• no-store is the real “don't keep this”: caches of any kind shouldn't store the response. Every visit downloads it in full. Used on images, fonts or scripts that rarely change, it throws away the benefit of caching.

Versioned file names make long caching safe

The obvious worry with a one-year max-age is: what happens when I change my logo? The answer is to change the file's address too. MDN calls this the cache-busting pattern: put a version number or hash in the file name (for example styles.3f9a2c.css) and, instead of editing a file in place, publish a new one with a new name. Returning visitors' browsers have never seen the new address, so they fetch it.

That leads to the combination MDN gives as an example:

• Versioned static files (images, fonts, scripts, stylesheets): Cache-Control: max-age=31536000, immutable
• HTML pages, whose addresses don't change: Cache-Control: no-cache, so the browser checks for a new version each time and picks up the new file names.

Ask your web person whether your site's build process or platform already adds versions to file names. Without them, a long lifetime on a file that is edited in place can leave returning visitors with the old copy until it expires.

Why caching doesn't change your grade

A GreenTracer check measures one initial, uncached load of the page with Google PageSpeed Insights, on mobile and desktop, and uses the heavier of the two. In other words, it measures a first visit, when nothing can come from the cache. Good caching therefore won't change your estimate or your grade.

It still matters. Returning visitors download less data when files are cached well, which also makes pages quicker for them. GreenTracer's estimate leans towards a first visit rather than discounting for that, as our guide to reading a report explains. To improve the grade itself, reduce what a first visit downloads: images, fonts and third-party tags are the usual places to start, and checking your page weight shows where it goes.

Check your own caching

1. Open the page in Chrome, open DevTools (F12) and the Network panel. Leave “Disable cache” unticked this time.
2. Load the page, then reload it. Google's documentation notes that requests are served from the browser cache on repeat visits, so compare the transferred total on the status bar after the first and second loads.
3. Click an image, font or script and look at its response headers for Cache-Control. Missing values, very short max-age settings or no-store on static files are worth raising.
4. Lighthouse, which powers PageSpeed Insights, has a cache policy check that flags static resources that aren't cached. Since the move to performance insights, it appears as a cache insight rather than the older audit.

Sources

• RFC 9111: HTTP Caching
• RFC 8246: HTTP Immutable Responses
• MDN: Cache-Control
• web.dev: prevent unnecessary network requests with the HTTP Cache
• Chrome DevTools: Network features reference
• Lighthouse: serve static assets with an efficient cache policy
• Chrome for Developers: moving Lighthouse to performance insights