You Fixed It but the Screen Has Not Changed — How Caching Works

This article covers the situation where you fixed it but the screen has not changed.

You fixed the code and deployed it, but when you open the page, it is still the old version.

The cause is usually not the code, but an old copy still sitting somewhere.

Whether only you see the old version or everyone does tells you where it is left.

What a cache is — returning a kept copy instead of fetching it again

A cache — which keeps something fetched once nearby and, from then on, returns that instead of fetching it again — exists so that the same thing is not fetched over and over.

Something fetched once is kept at hand, and from the second time on, that is what is used.

In exchange for speed, there is a stretch of time when it does not notice that something has been updated.

The length of that keeping is the lifetime (max-age) — the time a kept copy may be used without fetching again.

Until the lifetime expires, the local copy keeps being used even if you fix the server.

The less something changes, as with images and CSS, the longer the setting tends to be.

A fix does not show while the lifetime has not expired.

A cache returns an old copy

A cache keeps something fetched once nearby and returns that from then on.

It is faster because it does not fetch every time, but it does not notice when the server side is updated in the meantime, so you get a fix that does not show.

The three places a copy sits — in your browser, in the delivery path, and in the server

A copy sits in more than one place.

There are three places, nested, running from closest to the user outward.

The innermost one, the copy your own browser holds, is the browser cache.

The second one, the CDN — which places copies close to users and delivers from there — is built into many deploy targets from the start.

These three places differ in how you clear them and in how far the effect reaches.

Having the CDN's copy cleared is a purge — deleting the copy the delivery layer holds and making it fetch again.

Some setups purge automatically on every deploy.

What a forced reload is

With an ordinary reload, the local copy is sometimes used as is.

The action that forces a re-fetch is called a hard reload (a forced reload), and if you only want to check, opening the page in a window that keeps no history does the same thing.

Narrow it down by whether only you see the old version or everyone does

Rather than trying the three places from the top down, checking the range first finishes faster.

What you look at is whether people other than you also see the old version.

If it is only you, the cause is nowhere but inside your own browser.

If other people see the old version too, no amount of reloading at your end changes it.

The bottom one is the case where the new files never reached the public server in the first place.

If the build failed, what is published is still the previous output.

A reload that fixes it is not necessarily a solution

Reloading at your end gives you the new version, but that only swapped the copy on your one machine.

On users' devices, the old copy stays until the lifetime expires.

Change the file name and the old copy stops being used

Instead of going around clearing copies, there is a way to keep the old copy from being used at all.

It is to change the file name together with the contents.

Replace part of the file name with characters calculated from the contents, and the name changes every time the contents change.

If the name is different, the local copy is a different file, so it is not used.

This naming work is done automatically at build time.

You do not need to think up names yourself.

The entry point, index.html, is the one file whose name cannot change, so you keep its lifetime short.

Once the names of the files it loads are new, everything from there on arrives new automatically.

Once it is found at an earlier point, it does not go any further to fetch.

So if even one place still holds an old copy, the new version does not arrive.

Changing the name is surer than going around clearing copies

If the file name changes when the contents change, the local copy is a different file and is not used.

The build does this naming automatically, so you only keep the lifetime short for the entry file, whose name cannot change.