CDN Explained: How Edge Networks Make the Internet Fast

The internet feels fast because of CDNs (Content Delivery Networks). Without them, a user in India loading a website hosted in Virginia would wait 200-300ms per round trip due to physics. With CDNs, the same user fetches assets from a Mumbai or Bangalore edge location in 5-15ms. The 20x speedup transforms web experience.

This post covers how CDNs work, what they typically cache, how modern CDNs handle dynamic content, and the rise of edge computing as the next evolution.

What a CDN does

A CDN is a globally distributed network of servers (edge locations) that cache and serve content closer to users. The core flow:

1. User requests asset (image, page, API response)
2. DNS routes to nearest CDN edge
3. Edge checks if it has the asset cached
4. If hit: serves from edge (fast)
5. If miss: fetches from origin server, caches it, serves to user

Subsequent requests for the same asset are served from the local edge — typically 5-50ms vs 100-500ms from a distant origin.

What CDNs cache

Static assets (always)

• Images
• CSS files
• JavaScript files
• Fonts
• Videos
• Downloadable files (PDFs, executables)

These rarely change and are safe to cache aggressively.

Semi-dynamic content (often)

• HTML pages with personalization injected client-side
• Public API responses (e.g., product catalog)
• Search results for popular queries
• Marketing pages

Cache with shorter TTLs and clear invalidation.

Dynamic content (with care)

• Authenticated API responses (cache per user)
• Personalized pages
• Real-time data

Modern CDNs support edge-side personalization to enable caching even of personalized content.

Not cached

• POST requests (typically)
• Authentication endpoints
• Real-time WebSocket connections
• Per-request unique responses

How requests reach the right edge

Anycast routing

CDN providers use anycast — multiple edge locations announce the same IP address. Internet routing automatically directs each user to the topologically closest edge.

This is the most common modern approach (Cloudflare, Fastly).

DNS-based routing

DNS responds with the nearest edge IP based on user's location.

Older approach but still used (CloudFront uses a hybrid).

GeoDNS / latency-based routing

Routes users based on geography or measured latency to edges.

Used as enhancement to other methods.

Cache control headers

The browser, CDN, and origin coordinate caching via HTTP headers:

Cache-Control

• public: cacheable by anyone (CDN + browser)
• private: cacheable by browser only (not CDN)
• no-cache: must revalidate with origin
• no-store: don't cache at all
• max-age=N: cache for N seconds

Example: Cache-Control: public, max-age=3600 — cache for 1 hour.

ETag

Origin returns a unique identifier for each asset version. Browser/CDN can ask "do you still have version X?" — if yes, origin returns 304 Not Modified (no body, saves bandwidth).

Last-Modified

Timestamp of last change. Browser can ask "is it still the same as I have from time X?"

Vary

Indicates which request headers affect the response. Vary: Accept-Encoding means cached versions differ for gzip vs brotli vs uncompressed.

Misconfigured Vary causes either over-caching (wrong response served) or under-caching (multiple cache entries when one would suffice).

Cache invalidation

When content changes, CDN caches must update. Three approaches:

TTL expiration

Wait for cache TTL to expire naturally. Simple but slow (changes invisible until expiry).

Purge / invalidate API

Explicitly tell CDN to evict specific URLs. Most CDNs offer this; Fastly's instant purge is famously fast (<150ms globally).

Versioned URLs

Asset URLs include version (e.g., style.v123.css). New version = new URL = no cache hit; effectively forces refresh.

Common with build pipelines — webpack, Vite, etc. emit content-hashed filenames.

Edge computing

Modern CDNs run code at edge locations, not just serve cached files:

Cloudflare Workers

JavaScript/TypeScript code runs at edge. Used for:

• A/B testing routing
• Authentication
• Custom routing logic
• Image transformations
• Real-time personalization
• Edge-side rendering

Cold start: <1ms (V8 isolates, not containers).

AWS Lambda@Edge

Lambda functions running at CloudFront edge locations. Heavier than Workers (full Node/Python runtimes); higher cold start.

Vercel Edge Functions

Edge functions for Next.js apps. Built on Cloudflare Workers underneath.

Use cases for edge computing

• Auth checks before reaching origin
• Personalization without round-trip to origin
• Routing logic (e.g., A/B testing)
• Image manipulation (resize, format convert)
• Bot detection and blocking
• Rate limiting

The trend: more application logic moves from origin to edge for latency and cost reasons.

Edge KV stores

Modern CDNs offer key-value storage at the edge (Cloudflare KV, Workers KV; Fastly Compute@Edge with KV; AWS DynamoDB Global Tables).

Use cases:

• Feature flags
• A/B test variants
• User preferences
• Session data (with consistency caveats)
• Rate limit counters

Not for primary application data — eventually consistent, replication delays.

CDN security features

Modern CDNs include:

DDoS protection

Absorb massive attack traffic before it reaches origin. Cloudflare regularly absorbs multi-Tbps attacks.

Web Application Firewall (WAF)

Block common attacks (SQL injection, XSS, etc.) at the edge.

Bot management

Distinguish legitimate bots (Googlebot) from malicious ones; throttle or block.

Rate limiting

Per-IP or per-key request limits enforced at the edge.

TLS / HTTPS

Free certificates, modern protocol versions, automatic certificate rotation.

These features alone justify CDN use even without performance benefits.

Performance optimization techniques

HTTP/2 and HTTP/3

Modern CDNs serve content over HTTP/2 (multiplexed connections) and HTTP/3 (QUIC, lower latency). Origin can stay on HTTP/1.1.

Compression

Brotli/gzip at the edge. Compressed-once, served-many.

Image optimization

On-the-fly resize, format conversion (WebP, AVIF), quality optimization. Cloudinary, ImageKit do this exclusively; modern CDNs include it.

Tiered caching

First miss: regional cache. Second miss: origin. Reduces origin load.

Prefetching

CDN learns access patterns and prefetches related assets.

Common mistakes

• No cache headers from origin: CDN uses default behavior, often suboptimal
• Vary on User-Agent: creates a separate cache entry per user agent string — billions of variants, useless
• Caching authenticated content without per-user keys: serves user A's data to user B
• No purge strategy: stuck with stale content until TTL expires
• Ignoring origin protection: CDN absorbs traffic spikes, but a single uncached query path can still saturate origin
• Not using CDN for APIs: even API responses have caching opportunities
• Treating CDN as set-and-forget: cache hit rates degrade over time without monitoring

Monitoring CDN performance

Critical metrics:

• Cache hit ratio (target: 80%+ for static assets, 30-60% for dynamic)
• Edge latency (per region)
• Origin shield offload (% of requests not reaching origin)
• Bandwidth savings
• Error rates

Most CDNs provide these dashboards out of the box.

What to read next

• Caching strategies explained — caching at the application layer.
• Load balancers deep dive — adjacent edge tech.
• System design basics — broader context.
• API rate limiting strategies — often implemented at the edge.

CDNs and edge computing represent one of the most impactful infrastructure shifts of the past decade. They're cheap (often free for small sites), provide multiple benefits beyond speed (security, reliability, TLS), and increasingly run application logic. If you operate any production web service, your CDN strategy is a first-class architectural concern, not an afterthought.