A CDN is infrastructure that puts copies of your content physically closer to the user requesting it. The global internet is fast, but physics caps it: every 100 km of fiber adds roughly 0.5 ms of round-trip latency. A user in Tokyo fetching assets from a Virginia origin faces 150–200 ms just in transit. A CDN edge node in Tokyo cuts that to 5–15 ms. That difference is measurable in conversion rates.
What changed in 2026
- Edge compute became the default. Every major CDN now runs a V8-isolate or WASM runtime at the edge. Cloudflare Workers, Fastly Compute@Edge, and Vercel/Netlify Edge Functions let you execute logic — auth, A/B, personalization — before requests ever reach your origin.
- HTTP/3 (QUIC) is universal. All tier-1 CDNs speak QUIC to browsers and increasingly QUIC back to origins, eliminating head-of-line blocking and improving performance on lossy networks.
- AI inference moved to the edge. Lightweight models (< 7B parameters, quantized) run inside CDN PoPs to handle classification and moderation without a round-trip to a GPU cluster.
- Private CDN topologies emerged. Large teams now build tiered CDN meshes: a public CDN layer, a regional mid-tier, and an internal origin shield — all from the same control plane.
Core concepts
Point of Presence (PoP). A PoP is a CDN datacenter in a specific city. Major providers operate 200–600 PoPs globally. When a user makes a request, DNS or Anycast routing directs them to the nearest PoP.
Cache hit vs miss. On a hit, the PoP serves the stored response. On a miss, the PoP fetches from origin, stores the response, then serves it. Subsequent requests for the same resource hit the cache.
Cache-Control. The origin sets this header to tell the CDN (and browser) how long to cache a response.
Cache-Control: public, max-age=86400, s-maxage=31536000, stale-while-revalidate=3600
s-maxage overrides max-age for shared caches (CDN). stale-while-revalidate lets the CDN serve a stale copy while fetching a fresh one in the background — reducing perceived latency to zero on popular assets.
Vary header. Tells the CDN which request headers affect the response, creating separate cache buckets per variant.
Vary: Accept-Encoding, Accept-Language
Getting Vary wrong means either serving gzipped HTML to clients that can not decompress, or creating so many cache variants that your hit rate collapses.
What changed in 2026
| CDN capability |
Pre-2023 |
2026 |
| Edge compute |
Limited (Lambda@Edge only) |
First-class (Workers, Compute@Edge, Edge Functions) |
| Protocol |
HTTP/2 dominant |
HTTP/3/QUIC universal |
| Cache purge latency |
30–120 s |
< 1 s (tag-based, instant) |
| Origin protocol |
HTTP/1.1 or HTTP/2 |
HTTP/3 back-haul supported |
| AI at edge |
None |
Inference for small models |
How origin shield works
Without a shield, every PoP in the network can independently cache-miss back to your origin. If you have 400 PoPs and a cold cache, you can get 400 simultaneous origin requests for the same resource — a "thundering herd."
An origin shield inserts a single PoP as the "last line of defense" before your origin. All other PoPs miss to the shield first; only the shield misses to origin.
Browser → Edge PoP (miss) → Shield PoP (miss) → Origin
↑
(all other PoPs miss here)
In practice this reduces origin request volume by 80–95% for popular content.
Edge compute patterns
// Cloudflare Worker: A/B test at the edge
export default {
async fetch(request: Request): Promise<Response> {
const bucket = Math.random() < 0.5 ? "a" : "b";
const url = new URL(request.url);
url.hostname = bucket === "a" ? "origin-a.example.com" : "origin-b.example.com";
return fetch(url.toString(), request);
},
};
This worker runs in < 1 ms at the nearest PoP, adding zero perceptible latency while splitting traffic.
How to pick a CDN
| Requirement |
Recommended approach |
| Static site, low traffic |
Cloudflare Free / Vercel built-in |
| API with auth at edge |
Cloudflare Workers or Fastly Compute |
| Large media / video |
AWS CloudFront or Akamai |
| Enterprise SLA + support |
Akamai, Fastly, or AWS CloudFront |
| Edge AI inference |
Cloudflare AI Gateway (2025+) |
- Know your traffic pattern. Static-heavy sites benefit most from aggressive max-age. APIs with per-user responses often get 0% cache hit rate unless you architect for it.
- Set
s-maxage and stale-while-revalidate on every cacheable route. Defaults (no caching) are the most common misconfiguration.
- Use cache tags / surrogate keys for instant targeted purging. Purging by URL path is slow and error-prone.
- Enable origin shield from day one; it costs little and saves your origin on every traffic spike.
Common mistakes
No Cache-Control on API responses. Public API endpoints that do not change per user (country lists, config, product catalog) can cache for minutes — but most teams leave them no-store by default.
Ignoring Vary. If you gzip responses but do not Vary: Accept-Encoding, some CDNs serve the raw body to clients expecting gzip.
Caching HTML with a long TTL. HTML is usually personalized or changes with deployments. Use a short TTL (60–300 s) or rely on cache tags for instant purge.
Over-relying on purge. Purge is a reactive fix. Set TTLs that match your actual change cadence so purge is rarely needed.
Not measuring hit rate. You can not optimize what you do not measure. Every major CDN exposes cache hit ratio in its analytics — check it weekly.
What to skip
- Building your own CDN — unless you are at Netflix / Cloudflare scale, the economics are brutal.
- Disabling the CDN for staging — you need to test caching behavior before it hits production.
- Cache everything including auth-required pages — leaking private data via CDN cache is a serious security incident.
FAQ
Do CDNs work for APIs or just static files?
Yes, APIs can cache heavily if responses are public and reasonably stable. Add Cache-Control: public, s-maxage=60 to endpoints like /api/products and cache hit rates often jump past 80%.
What is the difference between a CDN and a reverse proxy?
A reverse proxy (e.g., Nginx) typically sits in one location in front of your origin. A CDN distributes that proxy globally across dozens or hundreds of PoPs.
How do I purge the cache after a deployment?
Use cache tag purging: tag all assets with a deployment ID, then purge that tag on deploy. Most CDNs support this via API in < 1 s globally.
Does HTTP/3 change how I configure my CDN?
Mostly not from a config standpoint — your CDN enables QUIC for you. Ensure you are not blocking UDP port 443 at your firewall, which QUIC requires.
Where to go next