Caching and CDNs

Caching is keeping a copy of something so it does not have to be made again. That is the whole idea. Everything complicated about it comes from one follow-up question: how does the copy know when it is out of date.

It is worth understanding as a buyer because caching is where a large part of a hosting or maintenance fee quietly goes, and because “it looks fine to me but the client says the change is not showing” is one of the most common support conversations in the industry. It is almost always a caching problem, and knowing that saves everyone a fortnight.

The layers, from the visitor outwards

Caching happens at several independent points between your server and your customer’s eye. Each holds its own copy, each expires on its own schedule, and each can be the one showing stale content.

Browser cache. The visitor’s own device keeps copies of files it has already downloaded — images, stylesheets, fonts, scripts. This is why the second page of a visit is faster than the first, and why your site feels quicker to you than to anyone else. You have the whole thing cached and your customers do not. Testing your own site while logged in on your usual browser tells you almost nothing about a first-time visitor.

CDN or edge cache. A network of servers in many locations, holding copies of your files near the people asking for them. Covered below.

Server-side page cache. On a database-driven site, the finished HTML of a page is stored after it is first assembled, so the next request is handed the stored copy instead of running the code and querying the database again. This is frequently the single largest performance difference between two sites on the same platform and the same hosting plan.

Object and query cache. A layer beneath that, storing the results of individual expensive operations so that even an uncached page is cheaper to build.

Application and build cache. On a static site the entire concept moves earlier: pages are assembled at publish time and there is nothing left to compute per request. This is caching taken to its logical end, which is why static architecture and speed keep appearing together.

What a CDN does

A CDN stores copies of your content on servers in many geographic locations and serves each visitor from a nearby one.

It genuinely does three things. It shortens the physical distance the data travels, which is a substantial benefit for an Australian audience and is the subject of Australian hosting latency. It absorbs load, because requests answered at the edge never reach your origin server, which is what keeps a site standing during a spike. And it usually brings adjacent infrastructure with it: certificate handling, modern protocols, compression, image transformation and a layer of protection against certain kinds of attack.

What a CDN does not do

It does not make your page lighter. A CDN delivers an oversized hero image from a nearby city instead of a distant one, and it is still an oversized hero image.

It does not speed up anything it cannot cache — personalised pages, logged-in sessions, form submissions, checkout steps and live data all go to the origin.

It does not fix a slow application. If a page takes a long time to generate, the CDN either serves a stale copy or waits for the origin exactly as the browser would have.

And it does not remove the need for the work in why websites are slow. A CDN is a delivery improvement layered over whatever you built. It changes how fast the parcel arrives, not what is in it.

The invalidation problem, stated plainly

Here is the trade in one sentence: a cache is fast because it does not check whether it is still correct.

Every caching layer holds a copy that was correct when it was made. Something has to decide when that copy stops being trustworthy, and there are only two mechanisms. Either the copy expires after a set period, in which case stale content is served until it does. Or something actively tells the cache to discard it, in which case somebody or something has to remember to send that instruction, at every layer, in the right order.

This is why the practical failure is so familiar. You update the price on a page. The server page cache still holds the old HTML. You clear that, and the CDN still holds its copy of the old HTML. You clear that, and your own browser still holds the old stylesheet from last week. Three layers, three separate clearances, and each was behaving exactly as designed.

The professional answer is not to clear caches manually. It is versioned filenames: when a stylesheet or script changes, the build gives it a new name, so the browser requests a file it has never seen and the old cached copy becomes irrelevant without anyone clearing anything. Assets get long cache lifetimes because their names change; HTML gets short lifetimes or explicit purging because its address does not. That combination is what makes aggressive caching safe.

The actual HTTP headers behind all of this

Underneath every layer above, a server tells a browser or a CDN how to cache a specific response using a small set of HTTP headers, and knowing their names makes a developer’s explanation checkable rather than opaque. The Cache-Control header carries the main instruction, most commonly a max-age value stating how many seconds a cached copy stays valid before it is considered stale. no-cache does not mean “do not cache” — it means the cache must revalidate with the server before reusing a stored copy — while no-store is the stronger instruction that actually forbids caching a response at all, which is what a checkout or a page containing personal data should carry. must-revalidate closes the loophole of serving a stale copy after max-age has passed even if the origin server is briefly unreachable. Two further headers let a cache revalidate cheaply instead of re-downloading everything: ETag, a short identifier that changes whenever the underlying file changes, and Last-Modified, a timestamp (conventionally given in GMT) for when the file last changed. A cache holding a copy can send either value back to the server and get a fast “still current” answer instead of the whole file again. A visitor forcing a hard reload in their browser is, in effect, manually telling their own browser cache to ignore all of this and ask the server fresh.

What to ask, and what to do about it

Ask a supplier which layers are in place, what the lifetimes are, what happens automatically when you publish an edit, and whether asset filenames are versioned. Ask specifically what to do when a change does not appear, and get the answer written down for whoever in your office will hit it first.

For yourself, adopt one habit: check changes in a private browsing window, and give any CDN a moment before concluding something is broken. That single habit removes most caching panic.

Who maintains all of this once the build is finished is a service question rather than a technical one, and it is priced in website maintenance cost — confirm whether the figures you are given include GST before comparing them. What sits inside a competent retainer is set out on web development services.