CDN: Edge Caching, Invalidation & Web Performance

Q: What is edge computing relative to CDNs?

The same infrastructure, generalized: instead of only serving cached bytes near users, edge platforms run your code near users. See Cloudflare Workers and Serverless Patterns.

CDN (Content Delivery Network)

A CDN is a globally distributed network of proxy servers that caches your content close to users. Instead of every request crossing the ocean to your origin server, a user in Tokyo gets your JavaScript bundle from an edge node in Tokyo — cutting latency from hundreds of milliseconds to tens.

Nearly every production website sits behind one (Cloudflare, CloudFront, Fastly, Akamai), and modern CDNs do far more than static caching: TLS termination, DDoS absorption, image optimization, and running code at the edge. Understanding cache headers and invalidation is what separates "we have a CDN" from "our CDN actually works."

TL;DR

A CDN serves cached copies of your content from edge locations near users; misses are fetched from your origin and cached for next time.
You control caching with HTTP headers: Cache-Control: public, max-age=... (and friends) tell the CDN what it may cache and for how long.
The winning static-asset strategy: hashed filenames + immutable + 1-year TTL — deploys change the URL, so invalidation is never needed.
HTML and API responses use short TTLs or stale-while-revalidate, or stay uncached.
The cache key (URL + selected headers/cookies) decides what counts as "the same" request — misconfigured keys cause both poor hit ratios and cache-poisoning leaks.
CDNs are also your security edge: DDoS absorption, WAF, bot filtering, TLS.

How It Works

DNS (or anycast routing) steers each user to their nearest edge. The X-Cache: HIT/MISS (or cf-cache-status) response header tells you which path a request took — the first thing to check when debugging.

Controlling the Cache

Cache-Control Directives

The Standard Recipes

Hashed filenames (which Vite/Webpack produce by default) are the key insight: content changes → filename changes → old cache entries simply stop being requested. No purge needed, ever.

The Cache Key

The CDN decides "have I seen this request?" using the cache key — by default the host + path, optionally plus query strings, headers (Vary), or cookies. Two classic failure modes:

Key too broad → users see each other's content (caching Set-Cookie or personalized HTML publicly — a data leak).
Key too narrow → hit ratio collapses (keying on all query params when ?utm_source= varies infinitely).

Normalize aggressively: strip marketing params from the key, Vary only on headers that truly change the response, and never let authenticated responses into a shared cache.

Invalidation

For non-fingerprinted content (HTML, images by stable URL, API responses), you need a story for "the content changed":

⚠️ "Purge everything" on every deploy nukes your hit ratio and hammers the origin. Purge precisely, or design URLs so you don't have to purge at all.

Beyond Static Files

Modern CDNs are full edge platforms:

Dynamic content acceleration — even uncacheable API traffic benefits: TLS terminates near the user, and the CDN keeps warm, optimized connections back to your origin.
Edge compute — Cloudflare Workers, CloudFront Functions/Lambda@Edge, Fastly Compute run logic (auth checks, rewrites, A/B bucketing, personalization) at the edge before requests reach you.
Image/media optimization — on-the-fly resizing, WebP/AVIF conversion, video segment delivery.
Security stack — DDoS absorption (the network's scale soaks volumetric attacks), WAF rules, bot management, and rate limiting at the edge. For many teams the CDN is the security perimeter.

Choosing a CDN

For most projects the honest answer is: use the CDN attached to your platform, or Cloudflare in front of everything else.

Common Mistakes

Caching Personalized Responses Publicly

A Cache-Control: public on a page containing "Hello, Alice" serves Alice's page to Bob. Authenticated responses are private, no-store unless you've deliberately designed per-user keys.

Long TTLs on Unversioned Assets

max-age=31536000 on /app.js (no hash) means users run year-old JavaScript after your deploy. Long TTLs are only safe with fingerprinted URLs.

Ignoring the Hit Ratio

A CDN with a 40% hit ratio is mostly a proxy. Check analytics: low ratios usually trace to query-param explosion, Vary: Cookie, or no-cache defaults from the framework.

Trusting Client IPs Behind a CDN

At the origin, remote_addr is the CDN's edge IP. Configure the real-IP header chain (Nginx real_ip module with the CDN's published ranges) or your logs, geo logic, and rate limits all see the wrong client.

Leaving the Origin Exposed

If attackers can reach your origin directly, the CDN's DDoS/WAF protection is decorative. Restrict origin ingress to the CDN's IP ranges or use authenticated origin pulls.

FAQ

Do I need a CDN for a small site?

Usually yes, because it's free: Cloudflare's free tier or your host's built-in CDN gives you TLS, caching, and DDoS cover with near-zero setup. The performance gain matters most for global audiences and asset-heavy pages — see Web Performance.

Does a CDN help API responses?

Directly, only if responses are cacheable (public catalog data: yes; per-user data: no). Indirectly, always — edge TLS termination and optimized origin connections shave latency even on 100% miss traffic.

CDN caching vs application caching?

Layers, not alternatives: the CDN caches full HTTP responses at the edge; application caching (Redis, in-memory) caches data and computation inside your stack. High-traffic systems use both — see Caching Layers.

How do CDNs affect SEO?

Positively: faster Core Web Vitals (especially TTFB and LCP) correlate with better rankings. Ensure the CDN forwards canonical headers correctly and doesn't cache error responses long.

What is edge computing relative to CDNs?

The same infrastructure, generalized: instead of only serving cached bytes near users, edge platforms run your code near users. See Cloudflare Workers and Serverless Patterns.