What a CDN Actually Does, and Why Your Site Is Slow Without One

Picture someone in Sydney opening your website. Your server lives in a data center in Northern Virginia, which is where a huge slice of the internet physically sits. The request they just made has to travel from Sydney to Virginia and back. That's roughly 16,000 km each way as the crow flies, and a lot further as the packet actually routes, because fiber doesn't run in a straight line across the Pacific.

Here's the part people skip past. Even if your server is infinitely fast and your visitor has a gigabit connection, that round trip takes time you cannot buy your way out of. Light in fiber moves at about 200,000 km per second, roughly two-thirds of light's speed in a vacuum, because glass slows it down.^[1]A single Sydney to Virginia round trip is bounded by physics at well over 150 milliseconds, and real networks make it worse. Now multiply that by the number of round trips a modern page load needs, and you start to see why the site feels sluggish even though nothing is “broken.”

A CDN, a content delivery network, fixes this by moving the content instead of the request. It's a fleet of servers spread across the world that keep cached copies of your stuff close to wherever your users are. The visitor in Sydney hits a server in Sydney. The bytes travel a few kilometers, not an ocean. That's the whole pitch, and it's a bigger deal than most people building websites give it credit for.

The bottleneck is latency, not bandwidth

This is the misunderstanding that sits under everything else. When a page feels slow, the instinct is to blame bandwidth, the “how much can I download at once” number on your internet plan. But for most web pages, bandwidth isn't what's hurting you. Latency is.

Latency is the time for one round trip, the request going out and the first byte of the response coming back. Bandwidth is the pipe; latency is the length of the pipe. You can widen the pipe all you want, and it won't make the pipe shorter.

A 5 KB chunk of HTML and a 5 MB video clip both pay the same latency tax before the first byte shows up. The video then spends real time streaming the bulk of its bytes, so it actually leans on your bandwidth. The HTML doesn't. Most page loads are dozens of small files, so they're dominated by latency, not bandwidth. Widening the pipe does nothing for them.

And latency compounds, because setting up a secure connection isn't one round trip. Opening a TCP connection is a handshake. Negotiating TLS, the encryption layer behind HTTPS, is more round trips on top of that. Then you ask for the HTML, read it, discover it references CSS and JavaScript and images, and go ask for those too. Each of those steps can be another trip across the ocean if your origin is the only place the files live.^[2]A page that needs four sequential round trips to Virginia from Sydney can burn most of a second before anything useful paints, and the user hasn't even started downloading the images yet.

Treat those first two numbers as directional, not precise. Real latency depends on routing, congestion, and the specific path. But the shape is right and it's the whole point: the gap between hitting a server on your continent and hitting one across the planet is an order of magnitude, and you pay that gap on every round trip a page needs. A CDN collapses the distance, so it collapses the latency.

Edge caching, cache hits, and the headers that drive it

The original job of a CDN is caching static assets at the edge. “Static” means files that are the same for every visitor: images, CSS, JavaScript bundles, fonts, video segments. “The edge” is the network of servers near users, as opposed to your origin, the one server (or cluster) where the canonical version lives.

The flow is simple. A user requests a file from the nearest edge server. If the edge already has a fresh copy, that's a cache hit, and it serves the file directly. Fast, no trip to the origin. If the edge doesn't have it, that's a cache miss. The edge fetches it from the origin once, hands it to the user, and keeps a copy so the next person nearby gets a hit.^[3]

What decides whether something is cacheable, and for how long, is mostly the response headers your origin sends. The one that matters most is Cache-Control. It tells the edge (and the browser) how to treat the file.

HTTP/2 200 OK
Content-Type: image/png
Cache-Control: public, max-age=31536000, immutable
ETag: "a1b2c3d4"
Age: 84213
CF-Cache-Status: HIT

# public        → any cache, including the CDN, may store it
# max-age       → consider it fresh for 31536000 seconds (one year)
# immutable     → the file will never change, don't even revalidate
# ETag          → a fingerprint, used to revalidate cheaply on a miss
# Age           → how long this edge has held the copy (seconds)
# CF-Cache-Status: HIT → this edge served it without touching origin

That immutable, one-year pattern works because of how modern builds name files. Your bundler stamps a hash into the filename, so app.9f3c1.js becomes app.7d2a0.js when the contents change. The old name and the new name are different files, so you can cache each one forever and never worry about serving a stale version. The HTML that points at them gets a short cache or none, so it always references the latest hashed assets.

One more piece worth knowing: origin shielding. Instead of every edge location fetching a cache miss directly from your origin, the CDN designates one tier as a shield. Misses funnel through it, so your origin sees a trickle of requests instead of a flood from every city at once.^[4] For a popular file, your origin might serve it to the CDN a handful of times a day total, even with millions of visitors.

It's not just caching anymore

If you learned what a CDN was a decade ago, you learned “it caches images close to users.” That's still true, but it's now the smallest part of the story. The edge network turned out to be useful real estate for a lot more than static files.

• TLS termination at the edge. The encryption handshake that costs multiple round trips can happen between the user and the nearby edge server instead of the faraway origin. Same security, far less latency, because the expensive negotiation is local.^[5]
• DDoS absorption. A distributed denial-of-service attack tries to drown your server in junk traffic. A CDN has enormous aggregate capacity spread across the globe, so it soaks up the flood across hundreds of locations before it ever reaches your origin. Your single server would have folded; the network shrugs.^[6]
• Edge compute. You can now run actual code at the edge, small functions that execute in the location nearest the user. Cloudflare Workers, Fastly Compute, and AWS Lambda@Edge let you do auth checks, A/B routing, redirects, and request rewriting without a round trip to origin.^[7]
• Image optimization. Many CDNs resize, recompress, and re-encode images on the fly, handing a phone a small WebP and a desktop a larger one, all from the same original you uploaded.
• Smart routing.The internet's default path isn't always the fastest one. CDNs measure congestion in real time and route around it across their private backbones, which often beats the public route even when the geographic distance is similar.

The way I think about it, a CDN stopped being a cache and became a programmable layer that sits between the whole internet and your origin. Caching is the feature that got it installed everywhere. The compute and security stuff is what makes it sticky.

The hard part is invalidation

There's a famous line in programming: there are only two hard things in computer science, cache invalidation and naming things.^[8] It's a joke, but the cache-invalidation half is real, and a CDN is where you feel it.

The problem is the flip side of the speedup. You scattered copies of your content across the planet. Now you change something, and you have to get every one of those copies to update, or some users keep seeing the old version. Serving stale content fast is its own kind of broken.

A few concepts carry the weight here:

• Cache keys.The CDN decides whether two requests are “the same” based on a key, usually the URL plus a few chosen headers. Get the key wrong, by including a header that varies per user or ignoring one that matters, and you either cache almost nothing or serve one user's content to another. Cache keys are quietly one of the most important things to get right.
• Purging. When content genuinely changes, you tell the CDN to drop it. Good CDNs purge globally in seconds, and let you purge a single URL or a tagged group rather than blowing away the whole cache.
• stale-while-revalidate. A directive that says: if the cached copy is a little stale, serve it immediately anyway, and refresh it in the background for the next request.^[3]The user gets a fast response now, and the cache quietly catches up. It's the pragmatic answer to “fresh or fast,” which is have both, accept a brief window of slightly old.

The honest version is this: caching is easy to turn on and easy to get subtly wrong. The bug you create isn't a slow site, it's a site showing the wrong thing to the wrong person, which is worse and harder to notice. Spend your thinking budget on the invalidation strategy, not the caching, because the caching mostly works on its own.

When you can skip one, and why most sites can't

Not everything needs a CDN. If you're building an internal tool that ten people in one office use, all sitting near the server, the distance you'd be optimizing barely exists. A CDN would add a layer of config and a cache to reason about for almost no benefit. Same for a single-region audience where every user is already close to your origin. Don't add infrastructure to solve a problem you don't have.

But “single region” is rarer than people assume. The moment your site is public on the open internet, your audience is global whether you planned for it or not. Search crawlers, someone sharing a link, traffic from a country you weren't targeting. The person on the far side of the planet has the worst experience of anyone, and they're the ones a CDN helps most. For any public-facing site, the default answer is yes, put one in front of it.

Which brings me to this blog, because it's a clean example. This site is a fully static export. Every page is pre-rendered to a plain HTML file at build time, and the images and scripts are just files too. There is no server rendering anything per request, nothing to compute, no database to hit. That makes it the ideal CDN citizen. Every single thing it serves is a cacheable file with a stable URL, which is exactly what an edge cache is built to hold. A static site behind a CDN is about as fast as the web gets, because after the first request in a region, every page is sitting on a server near the reader, and the origin is barely involved.

You don't have to think hard about which CDN, either. The big names, Cloudflare, Fastly, Akamai, and AWS CloudFront, all do the core job well. They differ at the edges, on compute models, pricing, and how programmable the edge is. For a static site, almost any of them turns a global audience's slow experience into a fast one with very little work. That's a rare thing in infrastructure: a large, real speedup that's genuinely easy to get.