What Is a CDN? How Content Delivery Networks Work

A content delivery network (CDN) is a geographically distributed system of proxy servers that stores cached copies of a website's content in data centers close to end users, so that a request for a page, image, video, or API response can be answered from a nearby server instead of traveling all the way back to the origin. The result is faster load times, less load on the origin server, and a buffer against traffic spikes and denial-of-service attacks. Nearly every large website and app you use daily runs behind one, even though the CDN itself is invisible to you.

What Is a CDN, Exactly?

At its core, a CDN sits between your visitors and your origin infrastructure. Instead of every request traveling to a single server (or a single region), a CDN maintains many "points of presence" (PoPs) around the world, each holding cached copies of your content. A request from a user in Tokyo gets answered by an edge server in or near Tokyo, while a user in London is served from a nearby European PoP, even though both are requesting the same page from the same origin.

Wikipedia's entry on content delivery networks describes this as a network built to improve "availability and performance" by distributing content geographically, often across multiple internet backbones. The idea isn't new: CDNs emerged in the late 1990s as the web outgrew the capacity of single data centers to serve a global audience, and they have since expanded well beyond static file delivery into video streaming, software distribution, and increasingly, dynamic and API content.

A CDN is not a replacement for web hosting. Your origin server, whether that's a traditional host, a cloud VM, or a platform like a framework such as Next.js deployed to a serverless backend, still holds the canonical version of your content. The CDN's job is to reduce how often clients need to reach that origin at all.

How a CDN Works: The Request Flow

Understanding a CDN means following a single request through it, step by step:

1. DNS or anycast routing. When a browser resolves your domain, the CDN's routing layer determines which edge location should handle the request, based on factors like the user's geography, current network conditions, and server load. Some CDNs use DNS-based routing; others use anycast, where many servers around the world advertise the same IP address and standard internet routing sends the request to the topologically nearest one.
2. Edge lookup. The request arrives at an edge server (sometimes called a point of presence). The server checks whether it already has a valid, unexpired copy of the requested content in its cache.
3. Cache hit. If the content is cached and still fresh — governed by a time-to-live (TTL) value from the origin's Cache-Control headers or a CDN-side cache rule — the edge server returns it immediately, without ever contacting the origin.
4. Cache miss. If the content isn't cached, or has expired, the edge server (or an intermediate "shield" node) requests it from the origin, stores a copy according to the caching rules, and returns it to the user. Cloudflare's caching documentation notes that when many simultaneous requests hit an uncached asset at once, only the first is forwarded to the origin; the rest wait and receive the same response, which prevents a "thundering herd" from overwhelming the origin.
5. Subsequent requests. Once cached, that content serves directly from the edge for every other nearby user until the TTL expires or the content is purged.

This flow is why CDNs dramatically cut both latency (the content is physically closer) and origin load (most requests never reach the origin at all).

Edge Caching and Latency Reduction

Edge caching is the foundational CDN function. By keeping a copy of frequently requested content, images, videos, stylesheets, scripts, and (on modern CDNs) even personalized or dynamic responses, at servers physically near users, a CDN cuts the round-trip distance data has to travel. Less distance generally means lower latency and faster perceived load times, particularly for users far from a site's origin region.

The caching layer behaves conceptually like an in-memory cache such as Redis sitting in front of a slower database: both exist to answer repeated requests from fast, nearby storage instead of re-computing or re-fetching the same data every time. The difference is scope and geography — a CDN's "cache" is distributed across hundreds of physical locations worldwide rather than a single data center.

Caching isn't unconditional, though. Origins control what's cacheable and for how long using standard HTTP headers, and CDNs layer their own cache rules on top. Google Cloud CDN's documentation describes this as reactive caching: content only enters a cache after a real client request passes through it, and caches can't be pre-warmed. A cache hit ratio — the percentage of requests served from cache rather than the origin — is one of the main metrics teams use to judge whether their caching strategy is working.

Origin Shielding, DDoS Protection, and Traffic Absorption

Beyond raw speed, CDNs protect the origin server itself. Two related mechanisms matter here:

Origin shielding (tiered caching). Instead of every edge PoP independently fetching from the origin on a cache miss, a CDN can designate a single "shield" or mid-tier cache that collects requests from multiple edge locations and makes only one request to the origin. Cloudflare calls its version of this Tiered Cache, describing it as "caching frequently accessed content in multiple locations for faster delivery and reduced origin traffic." The effect is fewer total requests reaching the origin, even as edge traffic scales up.

DDoS and traffic-spike absorption. Because a CDN's capacity is spread across a very large, distributed network, it can absorb far more traffic than any single origin server could handle, whether that traffic is a legitimate surge (a product launch, a viral post) or a distributed denial-of-service attack. Akamai states that its network can absorb attack traffic at a scale of over 100 Tbps, and Amazon CloudFront includes AWS Shield Standard, which defends against common network and transport-layer DDoS attacks at no extra charge. Fastly similarly bundles DDoS protection and a web application firewall directly into its edge platform. In all of these cases, malicious or excessive traffic is filtered or absorbed at the edge, before it ever reaches application infrastructure.

Major CDN Providers Compared

The CDN market includes dedicated vendors, cloud-platform-native services, and telecom-operated networks. Five names come up constantly:

Note that network-scale figures are self-reported and change frequently as providers expand; treat them as directional rather than exact at any given moment. Each vendor's own documentation is the best source for current numbers.

When Do You Actually Need a CDN?

Not every project needs one on day one, but a few signals make a CDN worth adopting:

• A geographically spread-out audience. If your users are in multiple continents but your origin lives in one region, a CDN is the most direct fix for inconsistent load times.
• Media-heavy content. Images, video, and large downloadable files benefit enormously from edge caching, both for speed and for reducing origin bandwidth costs.
• Traffic that spikes unpredictably. Product launches, breaking news, and viral moments can overwhelm an origin server; a CDN's distributed capacity absorbs that burst.
• Security exposure. Public-facing sites and APIs are DDoS targets by default. A CDN with built-in mitigation removes a major operational risk.
• APIs and dynamic endpoints. Modern CDNs cache and accelerate more than static assets — some support protocols like gRPC alongside traditional REST and WebSocket traffic, letting API responses benefit from edge proximity too.

Smaller, regional, low-traffic sites may see diminishing returns from a CDN, though most providers now make basic tiers free or inexpensive enough that there's rarely a reason not to use at least a lightweight CDN layer.

How to Pick a CDN

Choosing among providers comes down to a handful of practical questions:

• Where does your traffic actually come from? Match a provider's PoP footprint to your real user geography rather than chasing the largest headline network size.
• How much do you need to cache dynamic content? If your app is mostly static assets, nearly any CDN will do. If you need to cache personalized or frequently changing responses, look closely at how a provider handles dynamic caching and instant purging.
• What security features are included versus paid add-ons? DDoS protection, a web application firewall, and bot management are built into some plans and sold separately on others.
• How tightly is it coupled to your existing cloud? If your infrastructure already runs on AWS or Google Cloud, their native CDN services integrate with less configuration, though a vendor-agnostic CDN like Cloudflare or Fastly works in front of any origin.
• Do you need edge compute? Several CDNs now let you run custom code at the edge, not just cache content, which matters if you're building logic like redirects, A/B tests, or authentication checks close to the user.
• What's the pricing model? CDN pricing is usually based on data transfer, request volume, or a combination, and costs can vary significantly by region, so model expected traffic before committing.

What's Next: Getting Started With a CDN

If you're adding a CDN to an existing site or service, start small and measure before expanding scope:

1. Audit your current latency and origin load. Identify which regions have the slowest load times and which assets generate the most origin traffic — these are where caching will have the biggest immediate impact.
2. Start with static asset caching. Images, CSS, JavaScript, and fonts are the safest and highest-value things to cache first, with minimal risk of serving stale dynamic data.
3. Set explicit cache-control headers on your origin rather than relying entirely on a CDN's defaults, so you control exactly what gets cached and for how long.
4. Watch your cache hit ratio after rollout. A low hit ratio usually means your caching rules or TTLs need tuning, not that the CDN isn't working.
5. Layer in security and dynamic caching later. Once static delivery is solid, expand into DDoS protection, WAF rules, and caching for API or personalized responses as needed.

Most teams never need more than one CDN. Multi-CDN setups, where traffic is split or failed over across two or more providers, exist mainly for very large, latency- or availability-critical operations, and they add real operational complexity. For the overwhelming majority of sites and apps, picking one solid provider, configuring caching correctly, and monitoring hit ratios will capture nearly all of the performance and resilience benefit a CDN can offer.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage