Caching Explained Without the Jargon

What it is doing

Every time somebody requests a page, something has to produce it: read the content, apply the template, assemble the result.

That work is identical for the thousandth visitor as for the first, so doing it a thousand times is wasteful.

A cache keeps the finished result and hands out copies. The page is built once and served many times, which is why caching is the single largest speed improvement available to most sites and why it is switched on almost everywhere.

The layers, in order

The confusion comes from there being several, each independent, each holding its own copy.

• Your browser, which stores files it already fetched.
• A caching plugin on the site, storing finished pages.
• The server, which may cache at its own level.
• A content network, holding copies in many locations.
• Your own device, where a mobile network may also cache.

A change has to work its way through all of them. Clearing one and finding nothing has changed is the normal experience, and it is not a fault.

When it lies to you

The everyday version of the problem, and the reason most people encounter caching at all.

You edit a price, save it, reload the page, and the old price is still there.

Nothing is broken. A stored copy made before your edit is being handed out, and it will continue to be until it expires or is cleared.

The unnerving part is that different people see different things at the same moment. You see the old version, a colleague in another office sees the new one, and both are correct.

The support call that is not a bug

A customer says the site shows last month's opening hours. You check and it shows this month's.

Neither of you is wrong. Their browser is holding a copy from three weeks ago.

This is worth recognising quickly, because the alternative is a developer spending an afternoon looking for a fault that does not exist.

The diagnostic question is whether the person seeing the old version can see the new one in a private browsing window. If they can, it is a cache, and the site is fine.

Checking what a visitor actually sees

Your own browser is the least reliable place to check anything, because you have visited the page most often and hold the most stale copies.

A private window bypasses much of your browser's stored data and is the quickest honest check.

A hard reload, forcing the browser to fetch everything again, is the next step.

And a different device on a different connection, ideally a phone on mobile data, is the most reliable of all, since it shares nothing with your desktop.

Clearing it, in order

Order matters, because clearing an inner layer while an outer one still holds an old copy accomplishes nothing.

Work from the site outward: clear the site's own cache first, then the server's if it has one, then the content network, then your own browser last.

Clearing your browser first is the most common mistake. It removes your local copy, the page is fetched again, and the outer layers hand you the same old version, so it appears that clearing did nothing.

Most caching plugins offer a single control that clears everything they manage, and many can also clear a connected content network at the same time, which collapses several steps into one.

A worked example

A restaurant updated their opening hours before a long weekend and checked the site, which showed the new times.

They received four calls over the weekend from people who had driven over based on the old hours.

The site had a caching plugin and a content network. The plugin had been cleared automatically when the page was saved. The content network had not, and was serving copies from its own storage on a twenty-four hour expiry.

The owner saw the correct version because they were logged in, and logged-in visitors were being served uncached pages by design.

Everybody else saw the old hours for most of a day.

The fix was connecting the plugin to the content network so both cleared together, which took a support ticket and about ten minutes.

What should never be cached

Anything personal or changing, and this is where caching stops being merely inconvenient.

Pages showing somebody's account, basket, or order status.

Anything behind a login, where serving one person's cached page to another is a genuine privacy incident rather than a performance quirk.

Live availability, stock levels, and prices that change during the day.

Forms carrying a security token, which can fail confusingly when an old token is served.

Sensible caching set-ups exclude these automatically, and a misconfigured one showing a logged-in visitor somebody else's details is a serious fault worth checking for deliberately if your site has accounts.

Expiry, and why it is set long

Every cached item has a lifetime, after which it is fetched again.

Images, stylesheets and scripts are usually given long lifetimes, sometimes a year, because they rarely change and holding them saves a great deal.

Pages themselves are usually given short ones, from minutes to a day.

This is why an image update seems to stick so stubbornly while a text change appears quickly. The remedy for images is a new filename rather than clearing anything, since a different name is a different file and no cache has it.

The counter-case

Caching is not always the answer, and a few sites are made worse by it.

A site where nearly every page is personalised gains little, since almost nothing can be safely reused.

A site with very low traffic gains less than expected, because a cached copy often expires before a second visitor arrives to benefit from it.

And aggressive caching on a site that publishes time-sensitive information is a genuine risk, as the restaurant found. Where hours, availability or prices change often, shorter lifetimes and automatic clearing on save matter more than the extra speed.

The procedure

1. Check in a private window before assuming a fault.
2. Test on a phone on mobile data as the honest check.
3. Clear from the site outward, browser last.
4. Connect the plugin to your content network so both clear together.
5. Exclude account and checkout pages from caching entirely.
6. Rename image files rather than fighting their cache.

Step four prevents most of the situations that produce an angry phone call.

What you are actually paying for is covered in what hosting actually buys you.

Frequently asked questions

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.