Infrastructure · Content delivery

CDN Guide: How Content Delivery Networks Work and When You Need One

A CDN is one of the most over-recommended and least-understood pieces of web infrastructure. Treated as a magic speed button, it disappoints; understood as a caching layer with specific strengths, it pays off handsomely for the right workload. This guide explains how a CDN actually works, what it genuinely accelerates, and — just as important — the cases where bolting one on adds cost and complexity for no real benefit. The goal is to let you decide from architecture, not marketing.

What is a CDN?

A content delivery network is a network of servers spread across many locations whose job is to hold cached copies of your content near the people requesting it. Instead of every visitor’s request travelling to your single origin server — potentially thousands of kilometres away — it is answered by an edge server at a nearby point of presence, or PoP. The central idea is distance: light travels roughly 200 kilometres per millisecond in fibre, so a user 3,000 kilometres from your origin pays at least 15 milliseconds each way before any data even moves, multiplied across the connection and encryption handshakes.

The single most useful thing to understand about a CDN is what it does and does not change. It speeds up the delivery of assets that are already fast to generate by shortening the distance they travel. It does not make your application faster to compute. Everything else — hit ratios, time-to-live, origin shields, dynamic bypass — is operating detail around that one mechanism. Hold that distinction and every CDN decision gets clearer.

How does a CDN actually work?

When a visitor requests a resource, DNS or anycast routing steers the connection to the nearest healthy edge PoP. Anycast is the common method: many geographically separate nodes advertise the same IP address, and standard BGP routing delivers the request to the network-nearest one, with failover in seconds if a node goes down. The edge node terminates the TCP connection and performs the TLS handshake itself, which offloads encryption work from your origin, then checks its local cache.

From there it is a hit or a miss. On a cache hit, the edge node has a valid copy and returns it immediately — typically 8 to 30 milliseconds for a nearby user, with the origin never contacted. On a miss, the request travels up a tier hierarchy: to a regional cache, then to an origin shield, and only then to your origin. That shield is the unsung hero of the design: by funnelling all cache misses through a single aggregation point, it stops every PoP from hammering your origin independently, raises your overall hit ratio, and shrinks your egress. A well-tuned hierarchy keeps origin traffic under a few percent of total request volume for cacheable content.

# Cache headers reveal whether the edge served you or your origin
$ curl -sI https://example.com/assets/app.js
HTTP/3 200
cache-control: public, max-age=31536000, stale-while-revalidate=86400
age: 4127
cf-cache-status: HIT          # served from the edge, origin untouched
server-timing: cdn-cache;desc=HIT, edge;dur=12
 
# A MISS means the edge fetched from origin (this request paid full RTT):
cf-cache-status: MISS   age: 0
# Long max-age + versioned filenames (app.4f9a.js) = high hit ratio, no purges

The problems a CDN solves

The headline benefit is latency. A single origin in, say, Toronto adds 150 to 300 milliseconds of round-trip delay for users in Asia-Pacific, Europe, or South America; a CDN eliminates that penalty entirely for cached content by answering from a local edge. For a global audience this is the difference between a snappy site and a sluggish one, and it shows up directly in Core Web Vitals and time-to-first-byte.

The second benefit is origin offload, which is really a cost and resilience story. A catalogue serving ten million requests a day at a 95 percent hit ratio means your origin handles five hundred thousand requests instead of ten million — a twentyfold reduction in load. That same distributed mesh absorbs traffic spikes and flash crowds, reduces egress bandwidth costs by serving from cheaper edge capacity, and reroutes around outages without touching your origin. A CDN, used well, is as much an availability and budget tool as a speed tool.

What you can and can’t cache

Everything good about a CDN depends on your hit ratio, and your hit ratio depends almost entirely on what you serve. Static assets — images, CSS, JavaScript, fonts, video, documentation, marketing pages, and public API responses that are identical for every user — cache beautifully, hitting 90 to 99 percent with sensible Cache-Control headers and versioned filenames. The technique that ties it together is stale-while-revalidate, which lets the edge serve a slightly stale copy instantly while fetching a fresh one in the background, decoupling user latency from origin response time.

Dynamic, personalised content is the opposite story. Logged-in pages, shopping carts, per-user dashboards, and searches with an effectively infinite parameter space have a cache hit ratio near zero, because no two responses are alike — an e-commerce site full of active shoppers barely benefits from asset caching at all. The hardest operational problem here is invalidation: clearing changed content across hundreds of PoPs is genuinely difficult, which is why versioned URLs that sidestep purging are preferred. And the truth worth repeating: if your page takes three seconds to build because of a slow database or un-cached application code, the CDN delivers that three-second response from a closer edge — the three seconds still happen. A CDN is not a substitute for a fast origin.

CDN security: TLS, WAF, and DDoS at the edge

Because the edge terminates every connection, it is the natural place to enforce security, and modern CDNs lean into that. TLS is terminated at the edge node, offloading the handshake from your origin while still allowing inspection. A web application firewall and bot-management rules run at the edge, filtering malicious requests before they ever reach your infrastructure. For many sites this consolidation is a real simplification: one layer handles encryption, filtering, and delivery together.

The strongest security property is distributed absorption. Because an anycast network spreads traffic across many nodes, a volumetric DDoS attack is diluted across the whole mesh rather than concentrated on one server, and the sheer aggregate capacity of a large CDN dwarfs what most attacks can muster. Pairing that with an origin shield lets you lock your origin down to accept traffic only from the CDN, shrinking your public attack surface to almost nothing. The edge becomes both your accelerator and your first line of defence.

The edge beyond caching

In 2026 the edge does more than store files. Edge compute lets you run code at the PoP itself — Cloudflare Workers start in under a millisecond on lightweight isolate runtimes across hundreds of locations, and platforms like Lambda@Edge offer similar request-time logic. The practical uses are authentication and token validation, A/B routing, geo-based redirects, header manipulation, and image transformation, all executed at the edge without a round-trip to origin. The trade-off is real: edge compute consumes 15 to 30 percent of a PoP’s CPU on dynamic-heavy traffic, competing with raw byte-serving, so it is a capacity decision rather than free functionality.

The transport layer has moved too. HTTP/3 over QUIC now carries more than 40 percent of CDN-served traffic, trimming the handshake cost of every connection, and Brotli compression reaches roughly 97 percent of browsers — leaving a real compression gain on the table for anyone still falling back to gzip. The edge has also become a compliance tool: serving content from PoPs in specific regions helps satisfy data-residency rules, which connects content delivery to the kind of jurisdictional constraints that govern where data is allowed to live.

Do you actually need a CDN?

Often, yes — but not always, and the honest cases against one matter. If your audience is concentrated in a single region and your users are already close to your origin, the latency a CDN saves may be imperceptible while the configuration complexity, caching bugs, and extra point of failure are very real. Internal tools, admin panels, and B2B applications whose users all sit within one country or corporate network are classic examples where a CDN adds risk for no felt benefit.

The other disqualifier is content shape. If nearly every request produces a unique response — a search engine, an analytics dashboard, an app where each request carries user-specific parameters — your cache hit ratio approaches zero and there is simply nothing to cache. Low-traffic sites see negligible offload savings, and debugging is genuinely simpler without a cache layer obscuring whether stale data came from the edge or the origin. A CDN earns its place when you have cacheable content and geographically dispersed or high-volume traffic; absent both, it is overhead.

Why your origin server still matters

It is easy to talk about CDNs as if they replace your server, but they sit in front of one, and that origin is where everything uncacheable actually happens. Every cache miss, every dynamic page, every personalised response, and every write is generated by your origin — so its speed sets the floor for the experiences a CDN cannot accelerate. An origin shield protects it from miss storms, but it does not make it faster; only the origin itself does that.

This is why the strongest architecture pairs a capable origin with a CDN rather than treating the CDN as a crutch. A fast dedicated origin server generates dynamic content quickly and serves cache misses without becoming the bottleneck, while the CDN handles global static delivery — the two complement each other. The bare-metal versus cloud guide covers choosing that origin, and the bandwidth and latency primer covers the network fundamentals a CDN builds on. For heavier workloads, our Kubernetes, GPU, and LLM hosting guides go deeper on the compute behind the edge.

How do you choose and measure a CDN?

Ignore the headline PoP count, which is mostly marketing. Two hundred well-placed points of presence with strong local peering will beat four hundred clustered in North America and Western Europe, because what determines your latency is geographic distribution quality near your actual users, not a raw number. Look for an origin shield with request coalescing, support for the cache features you need — stale-while-revalidate, fine-grained purging — and route security such as RPKI-signed origins, since BGP route leaks can silently misdirect traffic and add tens of milliseconds.

Then measure relentlessly, because a CDN you do not instrument is a CDN you cannot tune. The metrics that matter are cache hit ratio broken out per region and per node, origin fetch latency, stale-serve rate, and error rate — averages hide the reality that users in one region may be suffering while others are fine. Watch the hit ratio above all: every percentage point you move it raises both speed and savings. Configure deliberately, instrument first, and treat the CDN as a measured system rather than a switch you flip and forget.