Why you sometimes see an old version of a website (and what Ctrl+F5 really does)

You push a change to your site. You reload. It still shows the old version. You reload again. Same. You try it on your phone and there it looks right, which makes it more confusing still.

Nobody broke anything. What you’re seeing is the cache, and it’s one of those things that stays mysterious until you know the rules, at which point it mostly stops being mysterious.

Why it exists

Every time you open a page, the browser needs dozens of files: HTML, stylesheets, JavaScript, fonts, images. Requesting all of them, every time, from a server that might be thousands of kilometres away would be absurdly slow.

So the browser keeps a local copy. Your second visit to a site is far faster than the first almost entirely because of this.

The problem is the one every copy has: deciding when it’s no longer valid.

Who keeps copies of your page

There isn’t one cache. There are several, chained together, and any of them can be serving you something different:

1. The browser’s memory cache, while the tab is open
2. The browser’s disk cache, which survives a restart
3. The service worker, if the site installed one — it can serve content without touching the network at all
4. Your internet provider’s cache, on some networks
5. The CDN, if the site uses one
6. The server cache, such as LiteSpeed Cache or Varnish

When “the change isn’t showing”, the real work is figuring out which of the six is handing you the old copy. Clearing the browser’s does nothing if the CDN is the one holding the old version.

The rules that decide

The server sends instructions alongside each file. The two that matter:

Cache-Control says how long the copy is good for:

• max-age=31536000 — valid for a year, don’t ask again
• no-cache — store it, but check whether it’s still current before using it
• no-store — don’t store it at all

ETag is a fingerprint of the content. The browser sends it back asking “is this still the one?”. If the server answers 304 Not Modified, the local copy is reused and no data travels. It’s a very cheap network request compared to downloading the whole file.

Note the important subtlety: no-cache does not mean “don’t cache”. It means “cache but revalidate”. The one that stores nothing is no-store. The naming is unfortunate and trips up a lot of people.

What Ctrl+F5 actually does

Here’s a difference almost nobody knows, and it accounts for a classic half hour of frustration:

Action	What it does
F5 or the reload button	Revalidates the HTML, but may reuse cached resources
Ctrl+F5 / Cmd+Shift+R	Requests everything fresh, ignoring the cache
Empty cache and hard reload (from F12)	Clears this site’s cache and reloads
Private window	Starts with an empty cache

And here’s the trap: Ctrl+F5 only affects your browser. If the old version is coming from the CDN or the server cache, you can press it a hundred times and nothing changes. You get the same thing, just faster at asking for it.

When the old copy arrives identically in a private window, in another browser, and on your phone over mobile data, the problem isn’t your browser. It’s upstream.

How well-built sites solve it

There’s a technique that removes the problem at the root, called cache busting.

Instead of serving styles.css, the build system generates styles.a7f3c9.css, where those characters are a fingerprint of the content. If the file changes, the name changes, and a new name is by definition a file the browser doesn’t have.

That allows the best of both worlds:

• Files with a fingerprint in the name can be cached for a full year, because they never change: when the content changes, it’s a different file.
• The HTML, which keeps its name, is served with mandatory revalidation. It’s small, so revalidating is cheap.

Every modern build tool does this automatically. It’s why a well-built site can be very aggressive with caching and still publish changes instantly.

The most annoying case: the service worker

If a site installed a service worker — installable web apps do — there’s an intermediary that can respond without consulting the network at all. There, Ctrl+F5 may not be enough.

Fix it from developer tools: F12 → Application → Service Workers → Unregister, then reload. If you build websites and see impossible behaviour, this is usually the culprit.

Diagnosis, in order

When something won’t update, this sequence finds the problem fast:

1. Open F12 → Network and tick Disable cache. Does it look right? Then it’s your browser and you know the server is fine.
2. Try a private window. Rules out cache and extensions at once.
3. Try mobile data on your phone. If it’s wrong there too, your network isn’t to blame.
4. Check the Size column in the Network panel: if it says (disk cache) or (memory cache), the file was never requested.
5. If you have a CDN or server cache, purge it. When the steps above turn up nothing, it’s almost always this.

The underlying idea

Caching isn’t a bug to work around: it’s what makes the web usable. Without it, every visit would be like the first.

What matters is understanding that there are several copies, in several places, with their own rules. When something won’t update, the right question isn’t “how do I clear the cache” but “which one is giving me this”. Framed that way, the answer usually appears in two minutes.