HTTP & Networking

Content Delivery Networks Explained: How They Speed Up the Web

A CDN's job is simple to state and surprisingly hard to run well: keep a copy of your content near every visitor, and know exactly when that copy has gone stale.

Published July 6, 2026

Without a CDN, every visitor's request travels all the way to your origin server, wherever that physically sits. A user in Singapore hitting a server in Virginia pays for that round trip on every request — often 200ms or more before your server has even started generating a response. A CDN puts copies of your content on servers distributed across many physical locations (points of presence, or PoPs), so that Singapore user's request gets answered by a PoP in Singapore instead.

How a request finds the nearest PoP

Most CDNs use anycast routing: the same IP address is announced from many physical locations, and standard internet routing (BGP) naturally sends each request to the topologically nearest one, without the client doing anything special. DNS-based routing is the older alternative — the CDN's DNS server resolves your hostname to a different IP depending on where the DNS query came from. Either way, the point is the same: the visitor doesn't pick a data center, the network does.

What actually gets cached

Static assets — images, CSS, JS bundles, fonts, video segments — are the easy case: they don't change per visitor, so a PoP can serve the exact same bytes to thousands of different users. Whether a PoP is allowed to cache a response, and for how long, is controlled by the Cache-Control header your origin sends:

Cache-Control: public, max-age=31536000, immutable

That header tells any cache (browser or CDN) it can keep the response for a year without re-checking, and that the content will never change at that URL — the standard trick for this is putting a content hash in the filename (app.a3f9c1.js) so a new deploy gets a new URL instead of trying to invalidate the old one. The full semantics of these directives, including the difference between max-age, s-maxage, and stale-while-revalidate, are defined in RFC 9111, the HTTP Caching specification.

HTML and API responses: the harder case

Dynamic pages and API responses can be cached too, just more cautiously. A product page that's identical for every logged-out visitor is a good candidate for a short TTL (say, 60 seconds) at the edge, which can absorb a huge fraction of traffic during a spike without hitting the origin at all. Anything personalized — a logged-in dashboard, a cart total — either skips the CDN cache entirely (via Cache-Control: private, no-store) or gets cached per-user with cookie/header-based cache keys, which most CDNs support but which multiplies your cache footprint fast if used carelessly.

Cache invalidation is the actual hard part

Setting a TTL is easy. Knowing you need to purge a specific URL right now, because the underlying content changed and 60 seconds is too long to wait, is where CDNs get complicated. Most provide a purge API to evict specific URLs or cache tags on demand:

curl -X POST "https://api.example-cdn.com/v1/purge" \
  -H "Authorization: Bearer $CDN_API_TOKEN" \
  -d '{"urls": ["https://example.com/products/42"]}'

Tag-based purging (invalidate everything tagged "product-42" regardless of URL) is more powerful than URL-based purging when one underlying change affects multiple cached pages, but it requires you to tag responses correctly at write time, which is easy to get wrong and hard to notice until a stale page ships.

Beyond caching: the other things a CDN does

Modern CDNs bundle TLS termination at the edge (closer to the visitor, faster handshakes), DDoS absorption (a distributed network can soak up volumetric attacks that would flatten a single origin), and increasingly, edge compute — running small pieces of your application logic at the PoP itself rather than round-tripping to origin. That last piece blurs the line between "CDN" and "distributed application platform," but the core value proposition hasn't changed: move the response closer to the request, and know precisely when to throw the cached copy away.

A cache hierarchy, not just one hop

It helps to picture caching as several layers stacked between the visitor and the origin, each with its own TTL: the browser's own cache, the CDN edge closest to the visitor, and sometimes a regional shield cache that sits between edge PoPs and origin specifically to reduce how many separate PoPs hit the origin directly on a cache miss. A busy CDN might have hundreds of edge locations; without a shield layer, a single cold cache entry could trigger hundreds of near-simultaneous origin requests the moment it expires. The s-maxage directive exists precisely to let you set a different, usually longer, TTL for shared caches like these than for the end user's own browser cache.