Two people open the same website at the same moment — one in São Paulo, one in Tokyo. Both pages load in well under a second, even though the company’s server sits in a single data centre somewhere in Europe. That is not magic, and it is not a faster internet connection. It is a CDN: a content delivery network. This article explains what a CDN does, how caching actually works, and when it is worth using one.
The problem a CDN solves
Data travels fast, but not instantly. Every request has to physically cross the distance between the visitor and the server, pass through routers along the way, and then make the return trip. The round-trip delay is called latency, and geography is its main driver.
Worse, a single page is rarely one request. A typical site pulls down HTML, several stylesheets, a handful of scripts, fonts and a dozen images. Each of those may involve its own round trip. Multiply a few hundred milliseconds of latency by dozens of requests and you get a page that feels sluggish, even on a fast connection.
There is a second problem. If every visitor worldwide hits the same origin server, that server carries the entire load — and a traffic spike can bring it down.
The core idea: bring content closer
A CDN is a network of servers — usually called edge servers or points of presence (PoPs) — distributed across many cities and regions. Each edge server keeps copies of your site’s files.
When a visitor requests a page, they are routed to the nearest healthy edge server rather than to your origin. The file travels a much shorter distance, so it arrives sooner. Your origin server, meanwhile, only has to serve the edges — not every individual visitor.
The routing itself typically happens through DNS or through anycast addressing, where the same IP address is announced from many locations and network routing naturally delivers the request to the closest one.
Cache hit, cache miss
Two terms cover almost everything you need to know about CDN behaviour:
- Cache hit — the edge server already has a valid copy of the requested file and serves it immediately. Fast, and no load on your origin.
- Cache miss — the edge does not have the file, or its copy has expired. It fetches from the origin, serves the visitor, and stores a copy for the next request.
Your cache hit ratio — the proportion of requests served from the edge — is the single most useful metric for judging whether a CDN is configured well. A low ratio usually means caching rules are too restrictive, or that URLs vary unnecessarily (for example, appending tracking parameters that make every request look unique).
Static versus dynamic content
| Type | Examples | Cacheable? |
|---|---|---|
| Static assets | Images, CSS, JavaScript, fonts, videos, PDFs | Yes — ideal CDN candidates |
| Semi-static pages | Blog posts, product pages, documentation | Usually, with a short expiry |
| Personalised content | Shopping cart, account dashboard, session data | No — must reach the origin |
| API responses | Varies | Sometimes, depending on the endpoint |
Modern CDNs handle uncacheable requests too, passing them through to the origin over optimised network paths — which is still faster than an unassisted connection across the world.
How you control caching
Caching behaviour is driven mainly by HTTP response headers. The three you will meet most often:
Cache-Control— sets how long a response may be stored and by whom. For example,max-age=31536000means “keep this for a year”;no-storemeans “never keep this”.ETag— a fingerprint of the file’s content, letting a client ask “has this changed?” and receive a tiny “no” instead of the whole file.Vary— tells the cache that responses differ depending on another header, such as language or encoding.
The classic problem: stale files
Long cache lifetimes make sites fast — and make updates invisible. You deploy a new stylesheet, but visitors keep receiving the old one from the edge for as long as the cache says it is valid.
Two standard solutions:
- Cache purging. Tell the CDN to discard specific files immediately. Useful, but it takes a moment to propagate across every edge.
- Cache busting through versioned filenames. Instead of
style.css, deploystyle.a7f3c9.css, where the suffix is a hash of the contents. A new version means a new URL, which is automatically a cache miss. The old file can safely be cached forever because it will never change.
Cache busting is the more robust approach and is built into most modern build tools by default.
What else a CDN gives you
- Resilience. If the origin is briefly unavailable, edges can keep serving cached content.
- Traffic absorption. Sudden spikes are handled by the edge network rather than one server.
- TLS termination. The encrypted handshake happens near the visitor, reducing setup time.
- Security features. Many CDNs bundle DDoS mitigation and a web application firewall.
- Image optimisation. Some can convert and resize images on the fly to match the visitor’s device.
When a CDN will not help much
A CDN is not a universal fix. It does little for:
- Sites whose audience is entirely in the same city as the origin server
- Slow database queries or unoptimised backend code — the bottleneck is on the origin, not the network
- Pages that are fully personalised and therefore uncacheable
- Heavy front-end JavaScript that blocks rendering after the files have already arrived
Measure before you assume. If your server takes 800 ms to generate the HTML, no amount of edge caching will fix that particular delay.
Conclusion
A CDN shortens the distance between your content and your visitors, and shifts load away from your origin. Configure cache headers deliberately, version your static assets, and watch your cache hit ratio — those three habits deliver most of the benefit.
To go further into web performance, hosting, HTTP and infrastructure, take a look at the free Web Development and IT courses available on Cursa.
