A website with a single origin server, however well provisioned, still has to send every byte across whatever physical distance separates that server from each visitor. A content delivery network (CDN) exists specifically to shorten that distance for as many requests as possible.

The core mechanism: caching closer to the user

A CDN operates a large number of servers, called edge locations or points of presence, distributed across many geographic locations. When a CDN is in front of a website, static content — images, stylesheets, scripts, and increasingly cacheable dynamic content — is stored (cached) at these edge locations, not just at the origin server. A user’s request is then routed to the nearest edge location holding a valid cached copy, rather than traveling all the way to the origin.

This matters because network latency has a physical floor set by the speed of light and the actual distance data has to travel — a floor no amount of server optimization can beat. AWS’s overview of CDNs frames the benefit directly in these terms: serving content from a location physically close to the requester reduces the latency inherent in that request, which a purely computational optimization at the origin server can’t achieve on its own. This is the same underlying geography discussed in Regions, Availability Zones, and Why Cloud Architecture Is Geographic — a CDN is, in effect, a way to have a presence in far more locations than running your own infrastructure in every relevant region would be practical or affordable.

What gets cached, and for how long

Not everything is equally cacheable. Static assets that rarely change — images, CSS, JavaScript bundles — are the easiest and most valuable content to cache, often for hours or days. Highly dynamic, personalized content is harder to cache meaningfully, though modern CDNs increasingly support more sophisticated caching rules, including caching parts of a response or caching for very short windows, to capture some benefit even for content that changes frequently.

Cache invalidation — telling the CDN a cached copy is now stale and should be refreshed from the origin — is a genuinely hard problem in practice; serving stale content because a cache wasn’t invalidated correctly is one of the most common CDN-related bugs teams encounter.

Beyond speed: absorbing load and some attack traffic

A CDN’s distributed capacity has a second, related benefit beyond latency: it absorbs a large share of total traffic before that traffic ever reaches the origin server, which means the origin can be provisioned for a smaller fraction of peak load than it would otherwise need. This also gives a CDN a natural role in absorbing certain categories of malicious traffic — high-volume request floods, in particular — since that traffic gets spread across, and partly absorbed by, the CDN’s distributed edge capacity rather than landing entirely on a single origin. A CDN is not a complete security solution on its own, but it’s a meaningful part of a layered defense against availability-focused attacks.

What a CDN doesn’t solve

It’s worth being precise about the limits. A CDN reduces latency for cacheable content and absorbs load, but it doesn’t speed up genuinely dynamic, uncacheable work happening at the origin — a slow database query is still a slow database query no matter how close the CDN edge is to the user. It also doesn’t replace proper load balancing at the origin itself, covered in Load Balancing Explained: Layer 4 vs. Layer 7, which handles distributing the traffic that does reach the origin across the servers actually capable of handling it.

Key takeaway

A CDN’s core value is physical: caching content at edge locations close to users shortens the network distance a request has to travel, which reduces latency in a way server-side optimization alone can’t. That same distributed footprint also absorbs a meaningful share of load and certain attack traffic before it reaches the origin — but it doesn’t make genuinely dynamic backend work any faster, which is still governed by the systems actually generating that content.

This article explains general CDN concepts; specific caching behavior, edge locations, and features vary by provider. See our disclaimer.