What Is a CDN? How Content Delivery Networks Work
Photo by Unsplash on Unsplash
Table of Contents
The One-Sentence Version
The first time I moved a site behind a CDN, the load time for overseas visitors dropped by more than half without me touching a single line of application code. It felt like cheating. The whole point is to defeat physics: data only travels so fast through fiber, and distance costs you real milliseconds.
This post explains what a CDN actually is, how edge caching works step by step, what belongs on a CDN and what doesn't, and the cache-control details that decide whether it helps you or quietly serves stale content.
The Physics Problem It Solves
A CDN sidesteps this by placing cached copies of your content within a few milliseconds of nearly every user on the planet. Instead of every visitor reaching all the way back to your single origin server, they hit the closest edge server in the CDN's network.
The building block is the Point of Presence (PoP) — a physical location where the CDN has deployed edge servers, typically wired into the local internet exchange points for fast last-mile delivery. Major providers run hundreds of PoPs across six continents. The more PoPs and the better their placement, the closer the cache is to any given user.
The second win is origin offload. Every request a CDN serves from cache is a request your origin never sees. That cuts your server's CPU, memory, and bandwidth use, which both saves money and keeps your origin responsive under traffic spikes. A viral post that would have melted a single server barely registers when 95% of requests are served from the edge. Lower latency for users *and* less load on your infrastructure — that combination is why CDNs are standard infrastructure now, not a luxury.
There's a third benefit people forget: resilience. Because a CDN sits between users and your origin, it absorbs a lot of abuse your server would otherwise eat directly. Most providers bundle in DDoS mitigation, bot filtering, and TLS termination at the edge, so a flood of junk traffic hits the edge network — which is built to soak it up — instead of your single box. I've watched a small site shrug off a traffic spike that would've taken it down a year earlier, purely because the CDN was doing the heavy lifting. You don't have to architect for that; it comes more or less for free the moment you're behind a CDN. And because the edge handles TLS, the expensive handshake happens close to the user too, shaving even more off that first connection.
How Edge Caching Works, Step by Step
Photo by Unsplash on Unsplash
1. A user requests a file — say `logo.png`. DNS routes them to the nearest edge server based on their geographic location, not to your origin. 2. The edge server checks its cache. Two outcomes from here. 3. Cache hit — the file is already cached at that PoP, so the edge server returns it immediately. This is the fast path, served in single-digit milliseconds, and your origin never hears about it. 4. Cache miss — the file isn't cached yet (first request to that PoP, or it expired). The edge server fetches it from your origin once, stores a copy, and returns it to the user. Every subsequent request at that PoP is now a hit until the cache expires.
That's the entire loop. The first visitor in a region pays the miss penalty; everyone after them gets the cached speed. Over time, your popular files end up cached at every PoP your traffic touches.
A detail that matters for tuning is the cache hit ratio — the percentage of requests served from cache versus those that fall through to your origin. It's the single number I watch when I'm judging whether a CDN config is working. A high ratio (say, 90%+) means the edge is doing its job and your origin is barely touched. A low ratio means something's forcing misses: cache headers that are too short, URLs with cache-busting query strings that vary needlessly, or responses marked uncacheable when they didn't need to be. I've fixed a sluggish site just by noticing the hit ratio was 40% because every asset URL carried a random query parameter, defeating the cache entirely — strip that and the ratio jumped, and so did the speed. Most CDN dashboards surface this number prominently, and it's the first place I look when caching "isn't working."
What controls how long a file stays cached is the `Cache-Control` header your origin sends. `Cache-Control: max-age=31536000` tells the CDN (and browsers) to cache the file for a year — perfect for versioned static assets that never change. `Cache-Control: no-store` tells it to never cache — right for personalized or sensitive responses. Getting these headers correct is most of the skill in using a CDN well; the MDN Cache-Control reference documents every directive. Set them too aggressive and users see stale content; too loose and your hit rate tanks.
What to Cache — and What Not To
Cache aggressively: static assets that don't change per user — images, CSS, JavaScript bundles, fonts, icons, downloadable files. These are the CDN's bread and butter. The trick is cache busting: give files a content-hashed name like `app.4f3a9b.js` so a new deploy produces a new filename. Then you can cache the old one for a year safely, because the new version has a different URL. Build tools do this automatically.
Be careful with HTML. Modern CDNs can cache full HTML pages, which is a massive win for mostly-static content like blog posts and marketing pages. But for pages that show user-specific data — a logged-in dashboard, a cart — you either skip caching or cache only the shared shell and load the personal parts separately. Caching a personalized page at the edge and serving it to the wrong user is a classic, embarrassing bug. The safe middle ground a lot of sites use is to cache the public version of a page and let logged-in requests bypass the cache, keyed off a session cookie. Some CDNs also support edge-side personalization, where the shared HTML is cached and small dynamic fragments are stitched in per request, but that's more setup than most projects need. When in doubt, I default to not caching anything that varies by user and only opt specific public pages in — it's far easier to add caching deliberately than to debug why one user saw another's data.
Never cache: authentication responses, anything with personal data, real-time API responses that must be fresh, and POST/PUT/DELETE requests. Mark these `no-store` or route them past the CDN entirely.
A few things worth knowing:
- Compression pairs with caching. A CDN typically compresses text assets with gzip or Brotli on the way out — I covered the difference in minification vs compression. Smaller files plus edge caching is the full speed combo. - Purging exists for emergencies. Every CDN lets you manually purge a file when you push an urgent fix that can't wait for the cache to expire. Use it sparingly; rely on cache busting for routine deploys. - A CDN isn't a backup or a CMS. It's a cache. Your origin remains the source of truth, and if it goes down, the CDN can only serve what it has cached.
For the broader set of utilities I keep open while debugging headers and payloads — formatters, encoders, converters — the ToolsFuel tools directory covers them. And when I'm checking an API response that's getting cached, I paste it into the ToolsFuel JSON formatter to confirm the structure before chasing a caching issue. Put your static assets on a CDN, set sane cache headers, keep personalized content off it, and your site gets faster everywhere at once.
Frequently Asked Questions
What is a CDN in simple terms?
A CDN, or Content Delivery Network, is a worldwide network of servers that stores cached copies of your website's files close to your users. Instead of everyone fetching files from your single origin server, each visitor gets them from the nearest edge server, which dramatically reduces load times. It mainly caches static assets like images, CSS, JavaScript, and fonts, and increasingly full HTML pages too.
How does CDN edge caching actually work?
When a user requests a file, they're routed to the nearest edge server, which checks its cache. If the file is cached (a hit), it's served in milliseconds and your origin never sees the request. If it's not cached (a miss), the edge server fetches it from your origin once, stores a copy, and serves it — so every request after that at the same location is a fast hit until the cache expires.
What should I not put on a CDN?
Don't cache authentication responses, anything with user-specific or personal data, real-time API responses that must be fresh, or write operations like POST and DELETE. Caching a personalized page at the edge and serving it to the wrong user is a classic bug. Mark those responses no-store or route them past the CDN, and reserve aggressive caching for static assets that are identical for every user.
Does a CDN compress my files too?
Yes, most CDNs compress text-based assets with gzip or Brotli as they're served, on top of caching them. That combination — smaller files plus edge delivery — is the full speed win. The compression is separate from minification, which happens at build time; I break down the distinction in [minification vs compression](/blog/minification-vs-compression-gzip-brotli-explained). Images shouldn't be gzip-compressed since they're already in their own compressed formats.
How long does a CDN cache my files?
It depends on the Cache-Control header your origin sends. Cache-Control: max-age=31536000 caches a file for a year, ideal for versioned static assets, while no-store prevents caching for personalized responses. Getting these headers right is most of the skill in using a CDN — too aggressive serves stale content, too loose tanks your hit rate. You can also manually purge files for urgent fixes.
Is a CDN worth it for a small website?
Usually yes, and many are free or nearly free at small scale. Even a modest site benefits from faster load times for distant visitors and protection against traffic spikes, since cached requests never touch your origin. The setup is mostly configuration rather than code changes, making it one of the cheapest performance wins available. Pair it with the free utilities in the [ToolsFuel tools directory](/tools) for the rest of your optimization work.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools