In short
A content delivery network stores copies of your files on servers around the world, so a visitor is served from somewhere near them rather than from your origin. It helps most when your audience is geographically spread and your content is cacheable. It helps least when nearly every response is personalised, and it does nothing useful if your cache headers tell it not to store anything.
What it does
A CDN keeps copies of your content on servers in many locations. When someone requests a file, they are served from the nearest one rather than from your origin server.
Two benefits follow. Latency falls, because physical distance is real — a request crossing an ocean costs over a hundred milliseconds regardless of bandwidth. And load on your origin falls, because most requests never reach it.
A modern CDN usually also handles TLS termination, compression, image optimisation, and denial-of-service absorption, which are often the practical reasons to adopt one.
When it genuinely helps
Your audience is geographically spread. If visitors are on another continent from your server, this is the largest single improvement available.
You serve substantial static assets. Images, video, fonts, scripts, stylesheets. These are cacheable, unchanging, and requested constantly.
Traffic is spiky. A CDN absorbs bursts your origin could not.
You want DDoS protection. Absorbing volumetric attacks is something CDNs do well and most origins do not.
Your site is mostly static. A static site behind a CDN is close to the fastest arrangement available, because nearly everything is served from cache at the edge.
When it adds little
Your audience is local and so is your server. A visitor 40km from your origin is already close. If you serve one country and host there, the latency gain is small.
Almost everything is personalised. A logged-in application where every response differs per user has little to cache. The static assets still benefit; the pages mostly do not.
Your site is tiny and slow for other reasons. A CDN does not fix a slow database query, a heavy JavaScript bundle, or a render-blocking font. Those are origin and client problems, and a CDN will faithfully deliver a slow page faster.
Cache headers decide everything
This is the part that determines whether a CDN does anything at all, and it is where most disappointment comes from.
A CDN caches according to what your origin tells it. If your responses say no-store, or omit caching directives so the CDN has to be conservative, it will forward nearly everything to your origin and you have added a hop for no benefit.
The pattern that works:
Fingerprinted static assets get a long cache lifetime and immutable. A file named with a content hash never changes, so it can be cached for a year. Deploying a new version produces a new filename.
HTML gets a short lifetime or revalidation. You want content updates to appear promptly.
Personalised responses are marked private so they are never stored at a shared cache — this matters, because a CDN caching a logged-in page and serving it to someone else is a serious data leak, and it happens.
Use stale-while-revalidate where a slightly old response is acceptable. It serves the cached copy instantly while refreshing in the background, which is often the largest perceived improvement available.
Invalidation
The standard problem: you updated something and the old version is still being served.
Fingerprinting avoids it entirely for assets — a new build produces new filenames, so there is nothing to invalidate.
For HTML, use short lifetimes plus explicit purging when you publish. Most CDNs offer purge by URL or by tag.
Be careful with aggressive HTML caching on sites with an admin interface: publishing a change and not seeing it is confusing, and the usual fix — someone purging everything repeatedly — removes most of the benefit.
Choosing one
For most sites the differentiators are practical rather than architectural: whether it has points of presence where your audience actually is, whether configuration is manageable, how quickly purging propagates, whether image optimisation is included, and what the pricing does when traffic spikes.
If your host already includes one, start there. An included CDN configured properly beats a better CDN configured badly, and the configuration is where the outcome is decided.
Before you add one
Check whether you have a distance problem. Look at your real-user performance data by country. If your visitors are concentrated near your server and the site is still slow, a CDN is not the fix — what is actually making it slow is somewhere else, and adding a CDN will disguise the investigation rather than resolve it.
If you do add one, set the cache headers deliberately at the same time. A CDN with default headers is frequently an expensive proxy.
If you are not sure whether latency or payload is your problem, book a call.
Common questions
What does a CDN actually do?
It stores copies of your content on servers in many locations, so visitors are served from somewhere near them rather than from your origin. That cuts latency, since physical distance costs real milliseconds, and reduces load on your origin because most requests never reach it. Most also handle TLS, compression, image optimisation and DDoS absorption.
Do I need a CDN for a small website?
Not necessarily. If your audience is concentrated in one country and you host there, the latency gain is small. A CDN also does nothing for a slow database query, a heavy JavaScript bundle, or render-blocking fonts — it will deliver a slow page faster without making it fast.
Why isn't my CDN improving performance?
Usually cache headers. A CDN caches according to what your origin tells it, so responses marked no-store — or omitting caching directives entirely — get forwarded to your origin anyway, adding a hop for no benefit. Fingerprinted assets should have long lifetimes; HTML should have short ones or revalidation.
How do I stop a CDN serving stale content?
Fingerprint static assets with a content hash so each build produces new filenames and there is nothing to invalidate. For HTML, use short cache lifetimes plus explicit purging when you publish. Avoid the pattern where someone purges everything after each change, which removes most of the benefit.
Can a CDN leak private data?
Yes, if personalised responses are not marked private. A shared cache storing a logged-in page and serving it to another visitor is a serious data leak, and it does happen. Mark anything user-specific as private so it is never stored at a shared cache.
