When you open a website for the second time, it usually loads noticeably faster than the first. That's no accident: your browser keeps copies of the files it already downloaded (the logo, stylesheets, scripts, fonts) and doesn't request them again. That's caching.
The catch is that badly configured caching fails in both directions: either your visitors download the same things again and again, or they see an old version of your site after you've changed it. Understanding how it works avoids both.
What caching is and where it lives
There are several layers. The browser cache sits on each visitor's device and avoids repeated downloads. The server cache (or page cache) sits on your hosting and stores the ready-built result of a page so it doesn't have to be generated from scratch on every visit. And in between there may be a CDN, a network that keeps copies of your files on servers close to the visitor.
Each one saves a different kind of work: the first saves transfer, the second saves processing on the server.
Cache-Control: the header in charge
Cache-Control is an HTTP header, meaning a message the server sends along with each file, telling the browser how long it may reuse it. These are the values you'll see most:
max-age=N: the file counts as valid for N seconds without asking the server again. For example,max-age=31536000is one year.no-cache: the name is misleading. It does store the file, but checks with the server that it's still valid before using it.no-store: don't keep anything anywhere. The right choice for pages with private data, such as a customer area.immutable: signals that the file won't change while it's valid, so the browser doesn't even revalidate it on reload.
You'll also see public and private, which say whether any intermediate cache may store the file or only the user's own browser.
ETag: asking before downloading again
When a copy expires (or when you use no-cache), the browser doesn't have to download everything again. Along with the file, the server sends an ETag, a kind of fingerprint of its content. Next time the browser asks: I have the version with this fingerprint, is it still good? If nothing has changed, the server replies with 304 Not Modified, without sending the file, and the browser reuses its copy.
It's slower than not asking at all, since there's still a round trip, but far lighter than downloading the whole file.
File versioning: how to bypass the cache when you need to
If you give your stylesheet a year of caching, how do visitors get the new one when you edit it? By changing its address. This is called cache busting, and there are two common ways: a parameter, like style.css?v=12, or a fingerprint in the filename itself, like style.4f2a9c.css. To the browser it's a different file, so it downloads it.
The combination that works best: static files (CSS, JavaScript, images, fonts) with versioned names and long caching with immutable; and the HTML with no-cache or very short caching, so it always points to the new versions. The classic mistake is long caching on unversioned files: visitors end up with new HTML and old CSS, and the site looks broken. A fingerprint in the name is sturdier than a parameter, because some intermediate caches ignore whatever comes after the question mark.
Server page caching and how to check it
If your site is generated with PHP and a database (like WordPress), every visit makes the server do work. A page cache stores the final HTML and serves it directly. It must be cleared when you publish changes, and personal pages such as the cart, checkout or private area should be excluded.
To see what's going on, open your browser's developer tools (F12), go to the Network tab and reload. In the size column you'll see (memory cache) or (disk cache) when a file comes from the cache, and a 304 status when it was revalidated. Click a file and, under Headers, look at its Response Headers to see Cache-Control and ETag. The Disable cache checkbox simulates a first visit while the tools are open. You can also run curl -I https://yourdomain.com/file.css in a terminal to see the headers without a browser.
Frequently asked questions
Why do I still see my old site after changing it?
It could be your browser cache, the server cache or a CDN. Try a hard reload (Ctrl+F5), a private window and, if nothing changes, clear the server or CDN cache. If your visitors are affected too, your files probably aren't versioned.
What max-age value should I use?
There's no universal value. For files with versioned names, one year is common; for HTML, no-cache or a few minutes. If a file changes often and you can't version it, use short times.
Does caching affect SEO?
Not as a direct factor, but good caching speeds up repeat visits and reduces server load, which helps the overall experience. What does hurt is serving outdated content or breaking the site through a badly planned cache.