A CDN, or content delivery network, is a globe-spanning network of servers that store cached copies of a website's content close to its users—so when you load a page or stream a video, it comes from a server near you instead of one continents away. This guide explains what a CDN is and how it works: why physical distance slows the web, how your request gets routed to the nearest server, what gets cached and what doesn't, and how CDNs also make sites faster and more secure. By the end you'll understand the invisible layer behind nearly every fast website you use.
What a CDN is and the problem it solves
Every website lives on an origin server—the authoritative machine (or cluster) where the real content and application logic reside. Without a CDN, every visitor's request travels all the way to that origin, wherever it physically sits. That's the problem a CDN exists to fix, and the root cause is the speed of light.
Data in fiber-optic cable travels at roughly two-thirds the speed of light, which feels instant but isn't when distances are large. A request crossing an ocean and back adds on the order of 100–150 milliseconds of unavoidable latency—the delay before data arrives—and a single page load involves many such round trips for the connection setup, the HTML, and dozens of assets. Stack those up and a distant origin makes a site feel sluggish no matter how powerful the server is. You can't out-engineer geography.
A CDN sidesteps the distance entirely. It operates edge servers in points of presence (PoPs)—data centers in cities around the world, often hundreds of them for a large provider. These edges hold cached copies of a site's content, so a user in Tokyo is served from a nearby PoP in tens of milliseconds rather than fetching from an origin in Virginia. Major CDNs like Cloudflare, Akamai, Fastly, and Amazon CloudFront now deliver an enormous share of all internet traffic this way.
How a CDN actually works, step by step
Two mechanisms make a CDN work: getting your request to the nearest edge, and serving content from a cache once it's there.
Getting you to the nearest edge
When a site uses a CDN, its owner points the domain at the CDN rather than directly at the origin—usually with a CNAME record or by delegating nameservers. From then on, the CDN decides which edge answers you, through one of two routing methods. With DNS-based routing, the CDN's name servers return the address of a PoP close to your resolver's location. With anycast, many PoPs announce the same IP address, and internet routing naturally delivers your packets to the nearest one. (If that routing layer is unfamiliar, our explainer on how DNS resolves a name into an address covers the foundation a CDN builds on.) Either way, you reach a nearby edge without knowing it happened.
Cache hits and misses
Once your request lands at an edge server, one of two things happens:
- Cache hit. The edge already has a fresh copy of what you asked for and serves it immediately. This is the fast path and the whole point of a CDN.
- Cache miss. The edge doesn't have it (or its copy expired), so the edge fetches it from the origin once, stores a copy, and serves it to you. Every later user in that region then gets a cache hit.
How long an edge keeps a cached copy is governed by TTL (time to live), set by the origin through HTTP headers like Cache-Control. A short TTL keeps content fresh; a long TTL maximizes the cache hit ratio—the percentage of requests served from cache—which is the single most important measure of a CDN's effectiveness. Most CDNs work in pull mode, lazily caching content the first time it's requested, rather than requiring the origin to push files out in advance.
What CDNs cache: static versus dynamic content
Not all content caches equally, and understanding the split is where people gain real intuition.
Static content is identical for every user—images, CSS and JavaScript files, fonts, downloads, and the video segments behind streaming. It's trivial to cache and is the bread and butter of any CDN. This is exactly why streaming services can deliver video to millions at once: the video is chopped into small segments, cached across thousands of edges, and served locally, with the player adapting quality to your connection.
Dynamic content is personalized or constantly changing—your logged-in account page, a shopping cart, live API responses. It can't be cached and reused, because one user's data must never be served to another. Modern CDNs still accelerate it through dynamic acceleration (optimized network routes and persistent connections between edge and origin) and increasingly through edge computing, where small programs run on the edge servers themselves to generate or customize responses close to the user rather than at the distant origin.
| Content type | Cacheable? | Typical handling |
|---|---|---|
| Images, fonts, downloads | Yes | Cached at edge, long TTL |
| CSS / JavaScript | Yes | Cached, versioned filenames for updates |
| Video segments (HLS/DASH) | Yes | Cached widely; adaptive bitrate |
| HTML pages | Sometimes | Cacheable if not personalized |
| Logged-in / cart / API data | No | Dynamic acceleration or edge compute |
Beyond speed: security and reliability
Caching is only half the value. Because a CDN sits between users and your origin, it becomes a powerful shield.
The biggest security benefit is DDoS protection. A distributed denial-of-service attack tries to overwhelm a site with junk traffic; a CDN's enormous aggregate capacity, spread across hundreds of PoPs, can absorb floods that would instantly crush a single origin. Most CDNs layer on a WAF (web application firewall) that filters malicious requests—SQL injection, exploit attempts—and bot-mitigation tools, all before traffic ever reaches your servers.
CDNs also handle TLS termination at the edge: the encrypted HTTPS connection is established at the nearby PoP rather than the distant origin, which speeds up the handshake while keeping traffic secure. If you want the details of that handshake, see our guide on how HTTPS encrypts and authenticates a connection. Finally, a CDN improves reliability: it shields the origin from sudden traffic spikes (a product launch, a viral post), and if the origin briefly goes down, edges can keep serving cached content so users barely notice.
When you need a CDN, and common mistakes
A CDN earns its place when you have a geographically spread audience, lots of static assets or media, unpredictable traffic spikes, or meaningful security exposure. A tiny site serving a single local town gains less. That said, given how cheap and often free entry-level CDN plans are, most public sites benefit.
A few mistakes recur:
- Caching personalized content. Misconfiguring cache rules so that logged-in or user-specific pages get cached is a genuine security incident—one user can be served another's data. Mark anything personalized as uncacheable.
- Bad or missing cache headers. Without sensible
Cache-Controlsettings, your hit ratio stays low and the CDN barely helps. Tuning TTLs is most of the work. - Forgetting to purge on deploy. Push new code or content but leave stale copies cached, and users see the old version. Invalidate or version your assets when you release.
- Treating a CDN as a fix for a slow origin. A CDN accelerates cacheable content, but a fundamentally slow, uncacheable application will still feel slow on its dynamic parts. Fix the origin too.
- Ignoring the last mile. A CDN gets content to an edge near you, but the final hop runs over your home network—a Wi-Fi 7 router or a mesh Wi-Fi system. A CDN can't rescue a congested local connection. One related quirk: routing your traffic through a VPN in another region changes your apparent location, so the CDN may serve you from a farther PoP and feel slightly slower.
Frequently asked questions
Do I need a CDN for a small website? You'll see the biggest gains with a global audience, heavy media, or traffic spikes, but because many CDNs offer free or low-cost tiers that also add security and TLS benefits, most public-facing sites are worth putting behind one. A purely local, low-traffic site gains the least.
Does a CDN host my website? Not usually. A CDN caches and delivers copies of your content, but the authoritative version still lives on your origin server, which the CDN fetches from on a cache miss. Some providers do bundle origin hosting or edge storage, but the core role is delivery, not hosting.
What's the difference between a CDN and a web host? A web host runs your origin server—the source of truth for your site. A CDN is a distributed caching and delivery layer in front of that origin, storing copies near users to cut latency, reduce origin load, and add security. They're complementary, not interchangeable.
Can a CDN slow my site down? Rarely, and usually through misconfiguration—caching the wrong things, low hit ratios, or an extra network hop for uncacheable dynamic content. Routing through a VPN to a distant region can also send you to a farther edge. Properly configured, a CDN almost always speeds delivery up.
How does a CDN know which server is closest to me? Through DNS-based routing, where the CDN returns the address of a nearby point of presence, or anycast, where many locations share one IP and internet routing picks the nearest. Both direct you to a close edge automatically, without any action on your part.
The takeaway
Understanding what a CDN is and how it works comes down to one idea: serving content from a server near the user beats serving it from one far away, every time. By caching content across a global network of edge servers, a CDN cuts the latency that distance imposes, lightens the load on your origin, and adds a strong layer of security and resilience on top. If you run a site, the practical next step is to put it behind a CDN, set sensible cache headers on your static assets, and watch your cache hit ratio—because the higher that number climbs, the faster and tougher your site becomes.