What is a CDN, and do you need one?
A CDN moves your files closer to your visitors. Whether that helps depends entirely on where your visitors are.
A content delivery network is a set of servers distributed around the world that keep copies of your site's files. A visitor gets served from the nearest one instead of from your origin server.
The benefit is latency. Physics sets a floor on how fast data crosses an ocean, and a CDN sidesteps it by not crossing one.
What a CDN actually speeds up
Static assets, reliably. Images, CSS, JavaScript, fonts. These are the bulk of most pages by size, and serving them from an edge location near the visitor is a genuine, measurable win.
HTML, only if configured to. By default most CDNs do not cache HTML, because it may be personalised. If your HTML still comes from the origin, your TTFB is unchanged — which surprises people who expected a CDN to fix a slow server. See what is TTFB.
TLS negotiation. The handshake happens with a nearby edge rather than a distant origin, which removes a round trip or two.
What it does not fix
- A slow application. If WordPress takes 900ms to build a page, a CDN does not change that unless it is caching the finished HTML.
- Oversized images. A 4MB hero image delivered quickly from an edge is still a 4MB hero image.
- Render-blocking scripts. Delivery speed is not the constraint; execution order is.
A CDN is a distribution optimisation. It does not make your site lighter or your server faster.
When you clearly need one
- Your audience is international. This is the strongest case by a distance.
- You serve a lot of media. Images, downloads, video.
- You get traffic spikes. The edge absorbs load your origin would otherwise take.
- You want the security layer. Most CDNs bundle DDoS mitigation and a WAF, which is often the real reason to adopt one.
When it changes almost nothing
- Your visitors and your server are in the same country. A UK site on UK hosting serving UK visitors is already about as close as it gets. The gain is marginal.
- Your site is small and light. A handful of pages and a few images will not notice.
- Your problem is server-side. Fix that first; the CDN will still be there afterwards.
That first case is the one most worth internalising. A lot of UK small-business sites add a CDN expecting a transformation and get nothing measurable, because the bottleneck was never distance.
Practical notes
Many hosts include one. Check before paying separately — several of the providers we cover bundle a CDN as standard.
Cache invalidation is the hard part. When you update a file, the edges need to know. Most integrations handle this; a misconfigured one serves stale CSS to some visitors and not others, which is a confusing bug to chase.
Watch the origin shield settings if you are on metered hosting — a badly configured CDN can increase origin requests rather than reduce them.
Check whether it is actually on. Use Who Hosts This Site? to see whether a CDN is detected in front of a domain. It is not unusual to find one configured and not actually serving traffic.
The honest order of operations
- Fix image sizes and formats
- Remove unnecessary scripts
- Get server-side caching working
- Then add a CDN
Doing it in that order means the CDN is distributing an already-fast site, which is what it is good at. Doing it in reverse means paying to distribute a slow one efficiently.