What Is a CDN and How Does It Work?

A CDN (content delivery network) is a global fleet of edge servers that cache copies of your content near your users. Anycast routing sends each request to the closest point of presence; on a cache hit the edge answers directly, on a miss it fetches from your origin and keeps a copy. Your Cache-Control headers decide what gets cached.

If your servers live in one data center and your users live everywhere, physics is working against you. A CDN is how you fight back.

What a CDN is

A CDN, or content delivery network, is a fleet of servers spread across the globe that store copies of your content close to your users. Each location is a point of presence, or PoP, and the machines inside it are edge servers. Instead of every request traveling all the way to your origin, most get answered by the nearest edge.

Why it matters

The core problem is distance. Every packet obeys the speed of light, and the round-trip time (RTT) between a user in Sydney and a server in Virginia is real latency you cannot code away. A page load involves many round trips, so that delay stacks up. Serving from a PoP 20 milliseconds away instead of 200 is a night-and-day difference.

Three more payoffs come beyond speed:

Origin offload: When edges answer most requests, your origin handles a fraction of the traffic. That means smaller bills and fewer capacity headaches.

Availability: If your origin hiccups, edges keep serving cached content, and a CDN spreads load so a spike in one region doesn't take everything down.

DDoS absorption: A large CDN has enormous aggregate bandwidth, so attack traffic gets soaked up across hundreds of PoPs instead of drowning your single origin.

How it works

Here is the flow. A user requests an asset, and anycast routing sends it to the nearest PoP automatically. With anycast, many PoPs advertise the same IP address, and internet routing steers each user to the closest one. Some CDNs layer geo-aware DNS on top, but the effect is the same: you land at the closest edge.

The edge checks its cache:

Cache hit: The edge has a fresh copy and serves it immediately. This is the fast path.

Cache miss: The edge has nothing, or a stale copy. It fetches from your origin, serves the response, and stores a copy for the next visitor. The first person pays the latency cost; everyone after them gets the hit.

What decides whether something is cached, and for how long? Your HTTP response headers. The Cache-Control header is the main lever. Here is a typical static-asset response:

HTTP/1.1 200 OK
Content-Type: image/png
Cache-Control: public, max-age=31536000, immutable

That max-age=31536000 tells the CDN to keep the file for a year, and immutable promises it will never change under that URL. The time-to-live (TTL) is that value counting down. When it hits zero, the edge treats the copy as stale and revalidates with the origin.

You can watch this with curl. Most CDNs add a header telling you whether they served from cache:

$ curl -sI https://example.com/logo.png | grep -i cache
cache-control: public, max-age=31536000
cf-cache-status: MISS

$ curl -sI https://example.com/logo.png | grep -i cache
cache-control: public, max-age=31536000
cf-cache-status: HIT

The first request warmed the edge; the second was served from it. That flip from MISS to HIT is the whole game. Cloudflare's header has more states worth knowing: EXPIRED (stale copy, refetched), REVALIDATED (origin confirmed the copy is unchanged), UPDATING (stale copy served while a refresh runs), and DYNAMIC or BYPASS (not cached at all). If you see DYNAMIC on a static file, your headers are the problem.

What to cache and what not to

Static content is the easy win: images, CSS, JavaScript bundles, fonts, and videos. These are identical for every user and change rarely, so a long TTL is safe.

Increasingly, teams cache more than static files. Cacheable API responses (a product catalog, a public price list) and even full HTML pages can live at the edge when they're the same for everyone. This is where big gains hide, since HTML is often the slowest part of a load.

What you should not cache is anything personalized or authenticated. A dashboard, a shopping cart, or any response tied to a login session must never be shared from a public cache. Serving one user's private page to another is a serious data leak. Mark those responses Cache-Control: private, no-store and keep them off the edge.

Cache keys, invalidation, and purging

How does the edge know whether two requests want the same thing? The cache key. By default it's usually the full URL, but you can tune it to include or ignore query strings, headers, or cookies. Too broad a key serves the wrong content; too narrow a key wrecks your hit rate.

The cache key is the CDN's version of the general key-design problem covered in our caching patterns guide.

The hard part of caching is getting rid of content on purpose. When you ship a fix, you need the edge to drop its old copy and pull the new one. That's invalidation, also called purging, and the approaches range from versioned filenames to explicit purge APIs. We go deep on this in our CDN cache invalidation strategies post.

Edge compute: the modern extension

CDNs started as dumb caches. Today they run your code. Platforms like Cloudflare Workers, Fastly Compute, and Lambda@Edge let you execute logic at the PoP, milliseconds from the user. You can rewrite requests, check auth tokens, personalize a cached page, or assemble a response from several sources without ever touching your origin. This turns the edge from a warehouse into a small distributed computer.

The leading CDNs

Four names dominate. Cloudflare is known for its large network, free plan, and Workers platform. Fastly is prized for fast purging by surrogate key and developer-friendly edge compute. Akamai is the veteran, with deep enterprise features. Amazon CloudFront integrates tightly with AWS, a natural pick if you already live there, and as of October 2026 it also sells flat-rate plans, starting with a $0 tier capped at 1M requests and 100 GB of transfer a month.

Pick on where your origin lives and how often you need to purge, not on network size claims, which every vendor measures differently.

When you need a CDN

You want a CDN when users span regions, when you serve meaningful static content, when traffic spikes threaten your origin, or when you need a shield against attacks. That describes nearly every public-facing site today.

You can skip it if your audience is tiny, local, and entirely behind a login, where almost nothing is cacheable. Even then, the DDoS protection alone often justifies the setup.

Questions people ask

What is the difference between a CDN and a web host?

A web host runs your origin: the server or platform that generates and stores your site. A CDN sits in front of it and keeps cached copies at edge locations worldwide, answering requests on its behalf. The host is the single source of truth; the CDN is a distributed cache. Many platforms now bundle both, but the roles stay separate.

How do I know if my site is served from a CDN cache?

Request a file twice with curl -sI and read the response headers. Cloudflare returns cf-cache-status, CloudFront returns x-cache with values such as Hit from cloudfront, and many CDNs add an age header showing seconds spent in cache. A first MISS followed by HIT means caching works; a persistent MISS, BYPASS or DYNAMIC means your headers or cache rules are blocking it.

Does a CDN help if my site is not static?

Yes, though less automatically. Even dynamic sites ship static assets, which a CDN caches outright. Public HTML and API responses that are identical for every user can be cached with short s-maxage values. Personalized pages stay private, but they still benefit from the CDN's TLS termination close to users, connection reuse to your origin, and DDoS absorption.

The call we'd make

Put a CDN in front of any public site from day one. The static-asset caching is basically free performance, the origin offload saves money as you grow, and the security posture is worth it on its own. Cache your static assets aggressively, keep authenticated responses off the edge, and get a deliberate invalidation strategy in place before you need it. For how this fits with DNS, routing, and the rest of the stack, see our networking fundamentals guide.

Sources

• RFC 9111: HTTP Caching
• MDN: Cache-Control header reference
• Cloudflare Docs: Cloudflare cache responses (cf-cache-status)
• Amazon CloudFront pricing