CDN Explained: How Content Delivery Networks Work

Your user is in Tokyo. Your server is in Virginia. Every single request travels 10,000km across the Pacific Ocean and back — that's 200-400ms of pure network latency before your server even starts processing the request. Multiply that by dozens of assets on a page and you've got a site that feels sluggish no matter how fast your code is.

A CDN fixes this by putting copies of your content on servers around the world. That same user in Tokyo now hits a server in Tokyo — 5ms instead of 300ms. This guide covers how CDNs actually work under the hood, what they cache, how to invalidate stale content, and how to pick the right one for your project.

What Is a CDN?

A CDN (Content Delivery Network) is a network of servers distributed across the globe — called edge servers or PoPs (Points of Presence). These edge servers cache copies of your content so users get served from the location closest to them instead of your single origin server.

Think of it like a library system. Instead of one central library where everyone in the country has to drive to, you put smaller branches in every neighborhood. People grab books from their local branch. The central library only gets involved when a branch doesn't have what someone needs.

Major CDNs operate 200-300+ edge locations worldwide. Cloudflare has servers in 300+ cities. AWS CloudFront has 450+ PoPs. No matter where your user is, there's likely an edge server within 50km of them.

Without CDN:
  User (Tokyo) → Origin Server (Virginia) → 10,000km round trip → ~300ms latency

With CDN:
  User (Tokyo) → Edge Server (Tokyo) → 50km round trip → ~5ms latency
  Edge doesn't have it? → Edge fetches from Origin → caches it → next user gets it instantly

Why CDNs Matter

CDNs aren't just about speed — though that alone is worth it. Here's what a CDN gives you:

How a CDN Works (Step by Step)

Here's what happens when a user requests a resource from a CDN-backed site:

┌──────────┐      DNS resolves to       ┌─────────────────┐
│   User   │ ──────────────────────────→ │  Nearest Edge   │
│ (Tokyo)  │                             │  Server (Tokyo) │
└──────────┘                             └────────┬────────┘
                                                  │
                                         Cache hit? ──→ YES → Return cached response (5ms)
                                                  │
                                                  NO
                                                  │
                                                  ▼
                                         ┌─────────────────┐
                                         │  Origin Server  │
                                         │  (Virginia)     │
                                         └────────┬────────┘
                                                  │
                                         Origin responds
                                                  │
                                                  ▼
                                         Edge caches response
                                         + returns to user
                                         (next request = cache hit)

The flow in plain English:

1. DNS resolution: User's browser resolves your domain. CDN's DNS returns the IP of the nearest edge server (anycast routing).
2. Edge lookup: The edge server checks its local cache for the requested resource.
3. Cache hit: If found and not expired, the edge serves it directly. Done in milliseconds.
4. Cache miss: If not cached, the edge fetches it from your origin server, caches a copy, then returns it to the user.
5. Subsequent requests: All future requests from that region hit the edge cache until TTL expires.

What CDNs Cache

CDNs can cache more than just images. Here's a breakdown of what's cacheable and what's not:

The golden rule: if a resource has a content hash in its filename (like app.a3f8b2.js), cache it for a year. The hash changes when the content changes, so users always get the latest version without you worrying about stale caches.

CDN Architecture: Push vs Pull CDN

There are two fundamentally different approaches to getting content onto CDN edge servers. Each has tradeoffs that matter depending on your use case.

When to use Pull: Most websites and APIs. You want the CDN to handle caching automatically. You change content frequently. You don't want to manage uploads.

When to use Push: Large static files that rarely change — video libraries, software installers, game patches. You want guaranteed availability without relying on an origin server.

Popular CDNs Compared

Here's how the major CDN providers stack up. Each has a sweet spot depending on your stack, budget, and scale.

My recommendation for most developers: start with Cloudflare. The free tier handles small-to-medium traffic, setup takes 5 minutes (just change your nameservers), and you get DDoS protection, a WAF, and SSL certificates for free. If you outgrow it or need tighter AWS integration, CloudFront is the natural next step.

Cache Invalidation

"There are only two hard things in Computer Science: cache invalidation and naming things." The quote exists for a reason. Here are your options for telling a CDN to drop stale content:

# Cloudflare purge
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {token}" \
  -d '{"files":["https://example.com/styles.css"]}'

# Fastly purge by surrogate key
curl -X POST "https://api.fastly.com/service/{id}/purge/product-123" \
  -H "Fastly-Key: {token}"

Cache-Control: public, max-age=3600     → Stale after 1 hour
Cache-Control: public, max-age=86400    → Stale after 1 day
Cache-Control: public, max-age=31536000 → Stale after 1 year (use with hashed filenames)

/assets/app.a3f8b2c1.js   → hash changes when code changes
/assets/styles.v2.css     → version bump forces new URL
/api/v2/users             → API versioning in path

Cache-Control: public, max-age=60, stale-while-revalidate=3600
// Serves cached content for 60s
// After 60s: serves stale + refetches in background for up to 1 hour
// After 1 hour of stale: full cache miss

CDN for API Responses

Caching static assets is obvious. But CDNs can also cache API responses — and this is where things get interesting (and tricky). Done right, you can serve API responses in 5ms instead of 200ms without hitting your database.

// Public product listing — cache for 5 minutes
GET /api/products
Cache-Control: public, max-age=300, stale-while-revalidate=600

// User-specific data — don't cache at CDN
GET /api/me/orders
Cache-Control: private, no-store

// Rarely changing reference data — cache for 1 hour
GET /api/countries
Cache-Control: public, max-age=3600

// Response header (Fastly, Cloudflare Enterprise)
Surrogate-Key: product-123 category-electronics homepage-featured

// Purge everything related to product 123:
curl -X POST "https://api.fastly.com/service/{id}/purge/product-123"

// Cache different versions based on Accept header
Vary: Accept
// Stores separate cached versions for:
//   Accept: application/json → JSON response
//   Accept: text/html        → HTML response

// Cache per language
Vary: Accept-Language

// ⚠️ Never use: Vary: *  (disables caching entirely)
// ⚠️ Avoid: Vary: Cookie  (creates a unique cache per user = useless)

Performance Impact: Before vs After CDN

Here are realistic latency numbers showing what a CDN actually does to response times. These are based on typical single-origin deployments vs CDN-backed setups.

Notice the "cache miss" row — the first request is actually slightly slower because it goes through the CDN edge AND then to origin. But every subsequent request from that region is served from cache. The tradeoff is worth it for any resource requested more than once.

The "full page load" improvement is 4x rather than 16x because pages include uncacheable elements (personalized content, fresh API calls). But even 4x faster is the difference between a bouncy user and a happy one.

Common CDN Mistakes

I've seen (and made) these mistakes enough times to know they're worth calling out explicitly:

CDN Best Practices

Follow these to get the most out of your CDN without shooting yourself in the foot:

Frequently Asked Questions

Related Articles