Short answer: Browser caching lets a visitor’s browser keep files it already downloaded, such as images, stylesheets and scripts, and reuse them instead of downloading them again. You control it with the Cache-Control header: a long max-age for files whose address changes with each version, and a check with the server for everything else.
How browser caching works
Every request the browser makes goes first to its own cache. If a stored copy is still fresh, the browser uses it and skips the network, which matters because latency costs a page far more than bandwidth.
The server says how long a copy stays fresh with the Cache-Control header. Once it is stale, the browser asks the server whether the file changed, using the ETag or Last-Modified value it stored.
If nothing changed, the server answers 304 Not Modified, with no file attached. Without any Cache-Control, browsers may still reuse a file that has a Last-Modified date for a while, which MDN calls heuristic caching. MDN says every response should set the header instead.
Which Cache-Control to use
| Kind of file | Cache-Control | Why |
|---|---|---|
| CSS and JavaScript with a version in the address | max-age=31536000 | A new version gets a new address, so a year is safe |
| Images and fonts with a version in the address | max-age=31536000 | The same reason: the address changes with the file |
| Files that keep their address when they change | A short max-age, or no-cache with ETag or Last-Modified | The browser keeps old copies briefly or checks first |
| HTML pages | no-cache or a short max-age | A page keeps its address, so visitors should get the current one |
| Personal or private answers | private or no-store | Shared caches, like a CDN, must not keep them |
From web.dev’s guide to the HTTP cache and MDN’s pages on HTTP caching, read November 4, 2026.
web.dev points out that once a browser has cached a file, you can’t make it fetch a new copy without changing the file’s URL. That is why the long lifetime goes only to versioned files.
How to set up browser caching
- Open your site in Chrome, open the developer tools and go to the Network tab.
- Reload, click a stylesheet or a script and read its Cache-Control response header.
- Run PageSpeed Insights and look at “Use efficient cache lifetimes” for the files it lists.
- Check that your stylesheets, scripts and images get a new address when they change, with a version number or a fingerprint.
- Give those versioned files a long max-age, such as a year, in your server, hosting panel or CDN.
- Keep HTML pages on no-cache or a short max-age, and leave ETag or Last-Modified on.
- Reload twice: the Size column should now say the files came from the memory or disk cache.
PageSpeed Insights asks for at least 30 days on cacheable files: fonts, images, media files, scripts and stylesheets. Our PageSpeed Insights guide explains the rest of the report.
Browser caching and SEO
Caching speeds up repeat visits and the pages a visitor opens after the first one. The first visit still depends on the server, which our TTFB guide covers.
Google says its crawlers support HTTP caching through the ETag and Last-Modified headers. It suggests setting both, since other software, such as content management systems, uses them too.
The protocol matters as well: our HTTP/2 and HTTP/3 guide shows how to check which version your site uses.
What we changed on our site
On the morning of November 4, 2026, our scripts went out with no Cache-Control header, and our stylesheets, images and fonts with 7 days. PageSpeed Insights listed between 297 and 315 KiB of cache savings on three of our pages.
Every stylesheet and script address on our site changes when the file changes: it carries the file’s date, a version number or a fingerprint. That made a year safe, so that same morning they started going out with max-age=31536000. Images and fonts kept 7 days, because their addresses don’t change with a new version. Our HTML pages carry no Cache-Control, ETag or Last-Modified, so browsers ask our server for the current page on every visit.
Read again after the change, the savings were between 183 and 206 KiB. Most of what is left is the Meta and OpenAI ad pixels, 162 KiB on each page, whose cache lifetime their own servers set.
Before you call your cache settings done
- Stylesheets and scripts get a new address with each version.
- Versioned files go out with a long max-age.
- HTML pages are not cached for long.
- ETag or Last-Modified is on.
- Personal answers are marked private or no-store.
- You know why each file PageSpeed Insights still lists keeps a short lifetime.
RememberCache for a year what changes address, and make everything else check with the server first.
Server settings like these are part of our technical SEO service.
Quick answers about browser caching
What is browser caching?
The browser keeps a copy of a file it downloaded, such as an image, a stylesheet or a script, and reuses it instead of downloading it again. The server says for how long with the Cache-Control header.
How long should files be cached?
PageSpeed Insights asks for at least 30 days for fonts, images, media, scripts and stylesheets. For files whose address changes with every new version, web.dev suggests a year: Cache-Control: max-age=31536000.
What is the difference between no-cache and no-store?
With no-cache the browser may keep the file but must check with the server before each use. With no-store, neither the browser nor any cache in between keeps a copy at all.
Will a long cache hide my changes from visitors?
Not if the file gets a new address with each version, through a version number or a fingerprint in the name. Without a new address, web.dev notes you cannot make browsers drop the copy they already have.
Does browser caching help SEO?
Indirectly. It makes repeat visits faster. Google says its crawlers support HTTP caching through the ETag and Last-Modified headers, and suggests setting both, since other software uses them too.
Sources
Read on November 4, 2026. web.dev: Prevent unnecessary network requests with the HTTP Cache. MDN: HTTP caching and Cache-Control header. Chrome for Developers: Use efficient cache lifetimes. Google: Overview of Google crawlers and fetchers (user agents). IETF: RFC 9111: HTTP Caching. Our case: the cache headers of our own files and PageSpeed Insights on three of our pages, before and after the change.