When a website loads quickly for someone in Tokyo and someone in São Paulo at the same moment, there is usually a CDN doing the quiet work in between. A CDN, or content delivery network, is a geographically distributed network of servers that keep copies of your content close to the people requesting it, so a photo or script does not have to travel all the way from one origin server on the other side of the planet.
That distance matters more than most people expect. Data moves fast, but it is still bound by physics and by every network hop along the way. A CDN shrinks the trip, and in doing so it changes how fast, how reliable, and how resilient a site feels under real-world conditions.
What a CDN is
A CDN is a network of edge servers, often called points of presence or PoPs, spread across many cities and regions. Each PoP can store cached copies of your content: images, stylesheets, JavaScript, video, and other files that do not change from one visitor to the next. Instead of every request going back to a single origin server, the CDN serves most of those requests from whichever edge location sits nearest the user.
The origin still exists. It is the authoritative source, the place where your content actually lives. The CDN sits in front of it as a caching and delivery layer. Think of the origin as a central warehouse and the PoPs as local shops that keep the popular items in stock, so customers rarely have to wait for a shipment from headquarters.
How a CDN works
The core mechanic is caching close to the user. When someone visits your site, the CDN routes them to a nearby PoP rather than to the distant origin. Routing usually happens through anycast, where many servers share one IP address and the network delivers each request to the closest one, and through DNS, which can hand different users the address of different edge locations based on where they are.
Once a request reaches an edge server, one of two things happens:
- Cache hit. The PoP already holds a fresh copy of the requested file and returns it immediately. This is the fast path, and it is where the CDN earns its value.
- Cache miss. The PoP does not have the file, so it fetches it from the origin once, serves it to the user, and stores a copy for the next person who asks.
Freshness is governed by a time to live, or TTL, which tells the edge how long it may keep serving a cached copy before checking with the origin again. A long TTL means fewer trips back to origin but slower propagation of changes. A short TTL means the opposite.
When you publish an update and cannot wait for the TTL to expire, you issue a cache invalidation, sometimes called a purge, which tells the edge servers to drop their stored copies and pull fresh ones. The combination of caching, TTL, and purge is what lets a CDN be both fast and reasonably current.
Why teams use a CDN
The benefits fall into three broad buckets, and most sites care about all three.
Performance. Serving content from an edge server a few hundred miles away instead of an origin several thousand miles away cuts latency, and lower latency means faster page loads. For image-heavy pages, video, and large scripts, the difference is easy to measure and easy to feel.
Scalability and availability. Because the edge absorbs the bulk of traffic, the origin sees far fewer requests. That offloading lets a site handle traffic spikes, a product launch or a viral post, without the origin buckling. If the origin briefly goes down, cached content can often keep serving, which raises overall availability.
Security. A CDN sits between the internet and your origin, which makes it a natural place to filter threats. Most CDNs offer distributed denial of service (DDoS) mitigation to absorb flood attacks, a web application firewall to block malicious requests, and TLS termination at the edge so encrypted connections are handled close to the user. The origin’s real address can also stay hidden behind the network.
Beyond static files: dynamic content and edge compute
Early CDNs were mostly about static assets, the files that look identical for everyone. Modern networks go further. They can accelerate dynamic responses by keeping persistent connections to the origin and by making smarter routing decisions, and many now run code directly at the edge.
These edge functions let developers execute logic, personalize responses, run redirects, or assemble pages near the user rather than at a central server. This blurs the old line between a CDN and a hosting platform. Some platforms build an entire deployment model around edge delivery, and services like Cloudflare Pages lean on that edge network to serve sites globally by default. The practical upshot is that a CDN today can be part of your application architecture, not just a delivery accessory bolted on at the end.
The major providers
A handful of providers dominate the space, and it is worth knowing the names even if the underlying ideas are the same across all of them:
- Cloudflare is widely used and known for a large network and a generous entry tier.
- Fastly is favored by developers for fine-grained control and fast cache purging.
- Akamai is one of the oldest and largest networks, common in enterprise settings.
- Amazon CloudFront is the CDN integrated into the AWS ecosystem.
Choosing among them usually comes down to price, the specific edge features you need, how well the provider integrates with the rest of your stack, and the quality of its network in the regions your users actually live.
Honest limits and trade-offs
A CDN is powerful, but it is not magic, and treating it as a cure-all leads to trouble.
Cache invalidation is famously one of the hardest problems in computing, and it bites in practice. Serving a stale copy after you have updated something, or purging too aggressively and hammering your origin, are both common failure modes that take real care to avoid.
A CDN also cannot fix a slow backend. If your database queries are slow or your origin takes two seconds to generate a page, the CDN speeds up delivery of whatever it can cache, but the uncacheable, dynamic parts still wait on that slow origin. Delivery and generation are different problems.
There is added cost and configuration to weigh. You are introducing another system, another bill, another set of settings that can be misconfigured. And the most dangerous mistake is caching the wrong thing. Cache a personalized dashboard or a page containing private account details, and a CDN will happily serve one user’s data to another. Deciding precisely what is safe to cache, and for how long, is where most of the real work lives.
None of this argues against using a CDN. For most sites that serve a meaningful amount of static content or a geographically spread audience, the performance and resilience gains are well worth it. It simply means a CDN is a tool with sharp edges, best deployed with a clear understanding of what it does and does not do.
Frequently Asked Questions
Do I need a CDN for a small website?
Not always. If your audience is concentrated in one region and your traffic is light, the gains may be modest. That said, many CDNs offer free or low-cost tiers, so the barrier to trying one is low, and the availability and security benefits can be worth it even at small scale.
Does a CDN replace my web host or origin server?
No. The CDN sits in front of your origin and caches copies of its content. Your origin remains the authoritative source where content is created and stored. Some edge platforms blur this line, but in the classic model the two work together.
What is the difference between a cache hit and a cache miss?
A cache hit means the edge server already holds a fresh copy of the requested file and returns it immediately. A cache miss means it does not, so it fetches the file from the origin, serves it, and stores a copy for future requests.
How does a CDN know which server to send me to?
Mostly through anycast routing, where many servers share one IP address and the network directs your request to the nearest one, and through DNS, which can return the address of a nearby edge location based on your position.
Can a CDN serve dynamic or personalized content?
Increasingly, yes. Modern CDNs accelerate dynamic responses and run edge functions that execute logic near the user. But personalized or private content must be handled carefully, since caching it incorrectly can expose one user’s data to another.
What is cache invalidation and why is it hard?
Cache invalidation, or purging, tells edge servers to drop stored copies and fetch fresh ones. It is difficult because it is easy to serve stale content by purging too rarely, or to overload the origin by purging too aggressively. Getting the timing right takes care.
Will a CDN fix a slow website?
Only partly. A CDN speeds up delivery of cacheable content and reduces load on the origin, but it cannot fix a slow backend or database. Uncacheable, dynamic requests still depend on how fast your origin can generate them.
Is a CDN worth it for a site with mostly local visitors?
Often yes, though for different reasons than distance. Even when every visitor is in one city, a CDN absorbs traffic spikes, terminates TLS closer to the user, and keeps serving cached pages when your origin is slow or briefly down. The gain is smaller than for a global audience, so weigh it against the cost and the added complexity of a second place where content can go stale.
