A content delivery network (CDN) is a network of servers distributed across multiple geographic locations that store cached copies of a website's static content, so a visitor's request gets served from a location physically closer to them instead of traveling all the way to the site's origin server. That's the entire mechanism — everything a CDN is useful for follows from that one idea, and everything it isn't useful for follows from its limits.
What a CDN actually does
When a CDN is in front of a site, a visitor's browser doesn't necessarily connect to the origin server at all for every request. Static assets — images, CSS, JavaScript, sometimes entire cached HTML pages — get copied out to edge servers (also called points of presence) in multiple regions, and a visitor's request gets routed to whichever edge server is closest to them, typically using DNS-based or anycast routing. If the requested file is already cached there, it's served directly from that nearby edge server. If not, the edge server fetches it from the origin once, caches it, and serves it to that visitor and every subsequent visitor routed to the same edge until the cache expires.
The problem it solves: geographic distance
Network latency is partly a function of physical distance — a request from a visitor in Singapore to an origin server in Madrid has to travel considerably farther than a request from a visitor in Barcelona, and that distance adds real, measurable delay before a single byte of content even starts arriving, independent of how fast the server itself responds. A CDN's edge network exists specifically to shorten that distance: instead of every visitor worldwide reaching the same origin server, most visitors reach a nearby edge location instead, cutting the geographic portion of that latency substantially for anyone far from the origin.
Origin offload: the other half of what a CDN does
The less-discussed benefit is what a CDN does for the origin server itself: every request served from an edge cache is a request the origin never has to handle. For a site under heavy traffic — a product launch, a viral post, a traffic spike from an ad campaign — this offload can be the difference between an origin server staying responsive and one buckling under concurrent connections it was never sized for. This is a genuinely separate benefit from latency reduction, and it's often the more decisive one for sites with unpredictable traffic spikes rather than a geographically distributed steady-state audience.
How a CDN decides what to cache, and for how long
A CDN doesn't guess at what's safe to cache — it follows caching rules, most commonly expressed through HTTP cache-control headers the origin server sends along with each response, specifying whether a resource can be cached at all and for how long (conceptually the same idea as the DNS TTL covered in DNS TTL Explained, applied to content instead of DNS records). A CSS file that rarely changes might be set to cache for a day or more; an HTML page that updates frequently might be set to a much shorter cache window, or marked as not cacheable at all. Getting this wrong in either direction causes real problems: caching something for too long means visitors can see stale content after an update until the cache expires, while caching too conservatively (or not caching cacheable content at all) gives up most of the benefit a CDN exists to provide. Most CDNs also offer a manual cache purge option, letting a site owner force an immediate refresh across edge locations right after a deliberate content change, rather than waiting out the normal cache window.
What a CDN doesn't fix
A CDN caches and distributes content faster — it doesn't make a slow database query faster, doesn't fix inefficient application code, and doesn't reduce the size of an unoptimized image before it's cached (though some CDNs offer separate image-optimization features as an add-on, which is a distinct capability from caching and distribution). A page that's slow because of server-side processing time, not network distance, will still be slow on first load at every edge location until that underlying cache is warm, and any uncacheable, personalized, or dynamic response (a logged-in dashboard, a cart page, a search results page built per request) generally bypasses the CDN's cache advantage entirely and still hits the origin every time. The performance fundamentals covered in What Makes a Business Website Fast and measured by Core Web Vitals for Business Websites are a separate, necessary layer — a CDN amplifies a fast site's reach, it doesn't substitute for the site being fast in the first place.
Does your site actually need one?
- Visitors are spread across multiple continents or regions far from the origin. If the audience is overwhelmingly local to where the server already sits, the latency a CDN removes was never large to begin with.
- Traffic is spiky or unpredictable. Origin offload matters more the less predictable the load pattern is.
- Most of the content is static or cacheable. A site that's mostly dynamic, personalized responses gets a smaller share of the benefit, since those requests typically can't be served from cache.
- Page weight is dominated by images, scripts or stylesheets rather than server processing time. A CDN speeds up delivery of those assets; it doesn't speed up what generates the HTML around them.
A single-location business site with a regional customer base and modest, steady traffic often doesn't need one — the latency it would remove was never large relative to everything else affecting load time. A site serving visitors across multiple countries, or one that needs to absorb unpredictable traffic spikes without the origin falling over, is a much more straightforward case for adding one. It's also worth sizing the decision to the actual audience split rather than treating it as all-or-nothing: a site with 90% of its traffic in one region and a small trickle from elsewhere gets most of the available benefit just from a well-located origin server, with a CDN mainly smoothing out the long tail rather than transforming the experience for the bulk of visitors — a different case from a site with genuinely global, evenly distributed traffic, where no single origin location is close to most visitors no matter where it's placed.
How a CDN fits with the rest of the stack
A CDN sits in front of hosting, not instead of it — the origin server still has to generate every response that isn't already cached, still runs the database, still needs enough capacity to handle cache misses and dynamic requests. Pairing a CDN with infrastructure that's already undersized for the application just moves where the slowness shows up, rather than removing it; see Understanding Scalability in Cloud Infrastructure for how origin capacity and distribution work together rather than as substitutes for each other. The practical sequence is usually: make sure the origin itself responds quickly, then add a CDN to extend that speed to visitors who are geographically far from it or to absorb traffic the origin alone couldn't handle smoothly. Adding a CDN also introduces one more layer to account for when something looks wrong — a visitor reporting outdated content after a fix was deployed is as likely to be a stale edge cache as it is a real bug, and knowing a CDN sits in the path changes where to look first.
