Caching keeps copies of your site closer to the visitor so pages load faster without rebuilding everything on every request. The confusion comes from there being several layers of it, each holding its own copy with its own expiry, so after an update one person sees the new version, another sees the old one, and both are looking at the same address.
Why caching exists at all
Without it, every visit means the server rebuilds the page, queries the database, and sends every image, font, and stylesheet again. That is slow and wasteful, particularly for content that has not changed since yesterday.
Caching stores the finished result and serves that instead. Done properly it is the single largest performance improvement available on a dynamic site, frequently taking a page from a second and a half to under a quarter of that. The trade is that a stored copy is by definition a copy of how things were, and something has to decide when it stops being good enough.
The layers, from closest to the visitor outward
| Layer | Where the copy lives | Who can clear it |
|---|---|---|
| Browser cache | On the visitor's own device | Only the visitor, or an instruction from your site telling it the file is new |
| CDN or edge cache | On servers distributed geographically | You, through the provider's controls |
| Page cache | On your own server, as finished pages | You, usually through the hosting control panel or a plugin |
| Object cache | On your server, as reusable pieces of data | You, and it usually clears itself as content changes |
An update has to work its way outward through these. Your server may hold the new version while a distributed edge server still holds the old one and a returning visitor's browser holds one older still.
The situation everyone recognises
You change a price, publish, reload, and see the old figure. Or the reverse: you see the new figure and a colleague on another machine does not, so you begin to doubt whether the change saved.
Both are the same phenomenon seen from different positions in the chain. The change is saved. What differs is which stored copy each person is being handed.
The instinct is a hard refresh, which forces your own browser to ignore its stored copy. That works, and it is also why this problem persists: it fixes the symptom for the one person who knows the trick and does nothing for the customers who do not. Confirming a fix by hard refreshing tells you very little about what everyone else is seeing.
Why stylesheets and scripts are the worst offenders
Page content is usually cached for minutes or hours. Stylesheets, scripts, and images are commonly cached for months, because they rarely change and caching them aggressively is a large part of why repeat visits are fast.
The consequence is that a design change can be live on the server and invisible to every returning visitor, potentially for a very long time, because their browser sees no reason to ask for a file it was told would not change.
The solution is versioned filenames. Rather than replacing a file with a new copy under the same name, the new version carries a different name, so the browser treats it as something it has never seen and fetches it immediately. Handled at build time this is automatic and invisible. Handled by hand it is the step people forget, and it is the specific reason a change can appear to have not taken effect days later.
What to clear, in what order
- The page cache on your server first, since everything downstream is copying from it. Clearing an edge cache while the server still serves the old page just re-copies the old page.
- The CDN or edge cache second, if you use one.
- Then check in a private window, which sidesteps your own browser cache without a hard refresh, and is closer to what a new visitor gets.
- Then check on a different device on mobile data, which is closer still.
Working inward rather than outward is the usual mistake, and it produces the impression that clearing the cache did not work when in fact it was cleared in the wrong order.
When caching is the actual problem
Occasionally it genuinely is: a shopping cart showing another visitor's contents, a logged-in area serving a cached public page, or a form token cached until it expires and every submission fails. These come from caching pages that should never have been cached, and the fix is exclusions rather than turning caching off.
The right response to a caching problem is nearly always to configure it properly rather than disable it, because a site with caching switched off is slower for every visitor in order to solve an inconvenience for a handful of people during updates. That trade is a poor one, and it is worth being clear about before someone suggests it as a quick fix.
Frequently asked questions
Why can I not see the changes I made to my website?
A cached copy is being served, most often by your own browser or by the page cache on the server. The change is saved; something between you and the file is still handing over an older version.
What is a hard refresh and should I rely on it?
It forces your browser to ignore its stored copy and fetch fresh files. It is useful for checking, but it only affects you, so it tells you nothing about what returning visitors are seeing.
In what order should caches be cleared?
Server page cache first, then any CDN or edge cache, then check in a private window and on a separate device. Clearing an edge cache while the server still holds the old version simply copies the old version again.
Why do design changes take longer to appear than content changes?
Stylesheets and scripts are usually cached for months because they rarely change, while pages are cached for minutes or hours. Versioned filenames solve this by making the browser treat an updated file as something new.
Should I turn caching off to avoid the confusion?
That trades a permanent slowdown for every visitor against an occasional inconvenience during updates. Where caching genuinely causes a problem, such as with carts or logged-in areas, the fix is to exclude those pages rather than disable it.
Does caching affect what search engines see?
Crawlers fetch pages like any other visitor and can receive a cached copy, so a badly configured cache can serve stale content to them too. Correct expiry settings and versioned assets prevent it.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
Changes not showing up the way they should?
We configure caching so your site is fast for visitors and your updates appear when you publish them, without anyone needing to know a keyboard shortcut.
Start a Conversation