What Is a CDN? How Content Delivery Networks Work
A content delivery network (CDN) is a distributed service that serves web content through servers closer to users while reducing repeated work at the origin. It can improve response time and absorb bursts of traffic, but those benefits depend on routing, cache policy, and whether the requested response is safe to reuse. This guide explains the request path, the difference between caching and edge compute, and a practical way to start with static assets.
What Is a CDN?
A CDN is a network of edge locations, often called points of presence (PoPs), connected to an origin such as a website, application, or object store. The CDN can keep reusable copies of eligible responses at its edges. A visitor asking for an image may receive a cached copy from an edge location instead of making every request travel to the origin.
Think of it as a network of local distribution centers: the origin remains the source of truth, while the CDN keeps selected copies nearby. A CDN can also provide TLS termination, traffic filtering, request routing, and programmable edge execution. For a broader technical treatment, see our CDN architecture and optimization guide.
Why CDNs Exist
Every network trip takes time. When a user’s request must travel to a distant origin and back, the round-trip delay affects page loads, downloads, and API response times. A CDN can shorten the delivery path for cacheable content and avoid repeating the same origin work for every visitor.
CDNs also help with:
- Origin capacity: Cached responses reduce repeated requests and bandwidth at the origin.
- Traffic bursts: Popular public content can be served by many edge locations rather than one application server.
- Media delivery: Large files and segmented video can be distributed closer to viewers.
- Security and availability: Many providers offer TLS, DDoS mitigation, bot controls, and web application firewall features. These controls complement rather than replace secure application design.
A CDN is not automatically useful for every workload. Private, frequently changing, or compute-heavy responses may not be cacheable, and a CDN cannot fix slow database queries or application code at the origin.
How a CDN Works: Request Path and Architecture
A typical request passes through several layers:
Client → DNS or anycast routing → edge PoP → cache and security rules → regional cache or origin on a miss → client
- Hostname resolution and routing: The client resolves a CDN hostname. Providers use DNS-based steering, anycast, or a combination to direct traffic to an available edge location. These mechanisms do not guarantee that a user reaches the geographically closest server; network conditions and provider policy also matter.
- Connection and inspection: The client establishes an encrypted connection to the edge. Depending on configuration, the CDN can terminate TLS and apply access, rate-limit, bot, or WAF rules before forwarding a request.
- Cache-key lookup: The edge determines whether it has a usable response for the request. The key commonly includes the hostname and path; query parameters, selected headers, cookies, and other dimensions should be included only when they change the response.
- Cache hit: If a matching entry is fresh and permitted by policy, the CDN returns it without contacting the origin.
- Cache miss or revalidation: The edge requests the content from a parent cache or the origin. Validators such as
ETagcan let the origin confirm that a stored response has not changed without sending the full body again. - Store and deliver: If the response and CDN rules allow it, the edge stores the response for its freshness lifetime, then returns it to the client.
A provider may add a regional cache or origin shield between edge PoPs and the origin. This tier can combine simultaneous misses and reduce origin load. Some CDNs also run configured code at the edge, but that is a separate capability from simply caching an HTTP response.
CDN Components and Delivery Models
| Component or model | What it does | Important consideration |
|---|---|---|
| Edge PoP | Terminates client connections and serves eligible cached responses | Routing is based on provider and network conditions, not distance alone |
| Origin | Supplies the authoritative response when the CDN cannot serve a usable copy | Protect it from direct access if traffic should pass through the CDN |
| Regional cache or origin shield | Reuses misses across multiple edge locations | Adds a cache layer whose status and freshness may need monitoring |
| Pull caching | Fetches an object from the origin after a cache miss | Simple to operate; the first request in a location can be slower |
| Push or pre-positioning | Uploads or copies selected content to the CDN before a request | Useful for predictable large releases; requires a publishing workflow |
| Edge compute | Runs configured logic close to users | Helpful for routing or lightweight processing, but adds code, limits, and debugging needs |
CDNs are sometimes confused with adjacent infrastructure:
| Technology | Primary job | What it does not guarantee |
|---|---|---|
| CDN | Deliver content from edge locations and optionally apply edge controls | Faster application computation when every request still needs the origin |
| Reverse proxy | Accept requests on behalf of an upstream server | A global edge network or distributed cache by itself |
| Load balancer | Distribute requests across healthy backends | Reuse of a response or reduced distance to the user |
| Edge compute platform | Execute logic at distributed locations | That responses are cached; caching must be configured separately |
Real-World CDN Use Cases
- Static site assets: Fingerprinted CSS, JavaScript, fonts, and images can be cached for a long time because a changed file gets a new URL.
- Downloads and software distribution: Large public files can be delivered from multiple locations, reducing repeated origin transfers.
- Video and audio: A CDN can cache media segments so viewers fetch them from a nearby edge. Live streams still depend on ingest, packaging, and freshness requirements.
- Public API responses: A
GETresponse shared by many callers may be cached briefly if its contents are not user-specific and the cache key captures all relevant inputs. - Dynamic applications: A CDN can still terminate TLS, filter traffic, and route requests even when personalized HTML is sent to the origin without being cached.
For edge workloads that execute logic rather than just reuse content, see the edge computing networking guide.
Practical Considerations and Setup Guide
Begin with a small set of public, versioned static files. Define cache behavior from the response’s sensitivity and change rate, not merely its file extension. The HTTP caching rules in RFC 9111 define directives such as max-age, s-maxage, private, and no-store. Provider cache rules can further adjust behavior: review the Cloudflare cache documentation and CloudFront expiration and TTL guidance before relying on defaults or overrides.
Example response policies:
# Only for fingerprinted assets, such as app.8f31c.js
Cache-Control: public, max-age=31536000, immutable
# A public page that browsers revalidate while a shared cache may keep it briefly
Cache-Control: public, max-age=0, s-maxage=60, must-revalidate
# A highly sensitive response that must not be stored
Cache-Control: private, no-storeno-cache does not mean “do not store”; it means a stored response must be validated before reuse. no-store prohibits storage. Shared caches can use s-maxage separately from a browser’s max-age. These semantics are specified in RFC 9111; CDN dashboards may also have minimum, maximum, or override TTL settings that affect the effective policy.
For a basic Nginx origin, a long-lived rule should be limited to files whose URLs change when their contents change. This example assumes every file under /assets/ has a fingerprinted name; otherwise, narrow the location or use a shorter cache policy:
location /assets/ {
add_header Cache-Control "public, max-age=31536000, immutable" always;
try_files $uri =404;
}Before routing production traffic through a CDN:
- Identify public, reusable assets and keep personalized or sensitive routes out of shared caching.
- Confirm what makes each response unique. Avoid broad cookie or query-string variation, but do not omit any value that changes the representation.
- Configure TLS for both the client-to-CDN and CDN-to-origin connections, and restrict direct origin access where practical.
- Test cache hits, misses, revalidation, purges, and origin failure behavior in a staging environment.
- Measure cache-hit ratio, origin request rate, latency, error rate, and bandwidth. Check egress, request, purge, and edge-compute pricing as traffic grows.
Inspect real response headers rather than assuming the configuration worked:
curl -sSI https://www.example.com/assets/app.8f31c.js
curl -sSI https://www.example.com/accountLook at Cache-Control, ETag, and any provider-specific cache-status header. Do not use a provider-specific status value as a portable HTTP standard. For programmable edge behavior, consult the Cloudflare Workers documentation; code running at the edge still needs explicit cache and privacy decisions.
Common CDN Misconceptions
- “The CDN always picks the nearest server.” DNS and anycast steer traffic according to provider policy and network routing. The selected PoP may not be the closest by physical distance.
- “A CDN makes every page faster.” A cache hit can reduce delivery time, but a miss still depends on the origin. Expensive application work remains expensive unless it is separately optimized or safely cached.
- “Cached content guarantees availability during an origin outage.” A fresh eligible copy may remain available, but expired objects, misses, and dynamic requests can fail. Stale-serving behavior depends on explicit provider and origin policies.
- “Everything should be cached.” A shared cache must not serve one user’s private response to another. Set a deliberate policy for authentication, cookies, query parameters, and personalized content.
- “A cache purge instantly fixes every stale copy.” Browser caches and other layers may retain their own copies. Versioned asset URLs are usually more predictable than relying on global purges.
