What Is a CDN and How Does It Make Websites Faster?

How content delivery networks work — edge locations, caching, cache keys and headers, invalidation, dynamic acceleration, security benefits, edge compute and how to use a CDN well.

By Danyal Ahmed - Data Scientist · · 4 min read

A content delivery network (CDN) is a globally distributed set of servers that caches and delivers content from locations close to users. When a visitor in Singapore loads your site hosted in Virginia, a CDN can serve most of the page from a nearby edge server instead of sending every request across the Pacific. The result: faster pages, lower origin load, lower bandwidth costs, and better resilience against traffic spikes and attacks.

Key takeaways

  • CDNs reduce latency by serving content from edge locations near users, cutting network round trips.
  • They cache static assets and, with care, HTML and API responses, based on HTTP caching headers and cache keys.
  • Cache hit ratio is the key metric: every hit is a request your origin never sees.
  • Use versioned asset URLs for long caching, plus purges or short TTLs for content that changes.
  • CDNs also provide TLS termination, DDoS protection, WAF and increasingly edge compute.

Why distance matters

Data travels through fiber at roughly two-thirds the speed of light. A round trip between continents takes on the order of 100–200+ ms. A new HTTPS connection needs several round trips (TCP and TLS handshakes) before the first byte of content. Multiply that by many assets, and distance dominates load time (what happens when you type a URL, latency numbers every engineer should know).

A nearby edge server turns 150 ms round trips into 10–20 ms ones.

How a CDN works

textUser (Singapore) ─▶ Edge (Singapore) ──hit──▶ response in ~10–20 ms
                          │
                         miss
                          ▼
                    (Regional/shield cache) ─miss─▶ Origin (Virginia)
  1. Routing: DNS or anycast directs the user to a nearby edge location.
  2. Cache lookup: the edge checks whether it has a fresh copy of the requested object.
  3. Hit: serve immediately.
  4. Miss: fetch from the origin (often via a mid-tier "origin shield" that consolidates misses), store it according to caching rules, and serve it.

The edge also keeps warm connections to the origin, so even uncached (dynamic) requests benefit from optimized routing and connection reuse.

What to cache

Content Cacheability Typical approach
JS, CSS, fonts, images with hashed filenames Excellent Cache for a year, immutable
Images and media Excellent Long TTL, image optimization at the edge
Public HTML pages (marketing, blogs, docs) Good Short TTL + stale-while-revalidate, or purge on publish
Public API responses Sometimes Short TTL; vary on relevant parameters
Personalized or authenticated pages Usually not Cache-Control: private or no-store

HTTP caching headers

The origin tells caches what to do:

http# Fingerprinted asset: cache "forever"
Cache-Control: public, max-age=31536000, immutable

# Blog page: fresh for 5 minutes at the CDN; serve stale while refreshing
Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=600

# Account page: never store in shared caches
Cache-Control: private, no-store
  • max-age: freshness lifetime for browsers (and CDNs, unless s-maxage is set).
  • s-maxage: freshness lifetime for shared caches (CDNs).
  • stale-while-revalidate: serve slightly stale content instantly while fetching a fresh copy in the background.
  • ETag / Last-Modified: allow cheap revalidation (304 Not Modified).
  • Vary: tells caches which request headers produce different responses (such as Accept-Encoding).

Cache keys

The cache key determines what counts as "the same" object: typically host plus path plus (some) query parameters.

  • Strip irrelevant parameters like tracking tags (utm_*), or they'll fragment your cache and destroy the hit ratio.
  • Be careful with Vary on headers like User-Agent or Cookie, which can create near-infinite variants.
  • Never include private data in cacheable responses. A misconfigured cache key that serves one user's page to another is a serious security incident.

Invalidation strategies

  1. Versioned URLs (best for assets): app.3f9a2c.js. Deploying new code produces new URLs, so no purge is needed, and old files can be cached forever.
  2. Short TTLs + stale-while-revalidate for content that changes unpredictably.
  3. Purge on publish: call the CDN's purge API when content changes. Tag-based purging ("purge everything tagged product-42") scales well.
  4. Avoid purge-everything on each deploy. It causes a thundering herd of cache misses to your origin.

Same principles as application caching: caching strategies.

Beyond caching

  • TLS termination at the edge: faster handshakes close to users; modern protocols (HTTP/2, HTTP/3).
  • Compression and image optimization: Brotli, WebP/AVIF conversion and resizing on the fly.
  • DDoS absorption: huge distributed capacity soaks up volumetric attacks.
  • Web application firewall (WAF) and bot management at the edge.
  • Load balancing and failover across multiple origins or regions (how load balancers work).
  • Edge compute: run small functions at the edge for redirects, A/B routing, authentication checks, header manipulation, personalization and even lightweight APIs.

CDNs and SEO

Page speed contributes to user experience signals like Core Web Vitals, and faster sites convert better. A CDN typically improves Time to First Byte (TTFB) and LCP for global audiences (Core Web Vitals guide). Make sure:

  • Canonical URLs and redirects behave consistently at the edge.
  • Bots aren't accidentally blocked by overly aggressive bot rules.
  • HTML caching doesn't serve stale content long after important updates.

Measuring CDN effectiveness

  • Cache hit ratio (requests and bytes), ideally broken down by content type.
  • Origin offload: how much traffic never reaches your servers.
  • Edge TTFB vs origin TTFB.
  • Real user monitoring by region.
  • Error rates at the edge (5xx from the origin, 4xx spikes).

Low hit ratios usually come from missing cache headers, fragmented cache keys, or Set-Cookie on responses that should be cacheable.

FAQ

Do I need a CDN for a small website?

If your audience is spread geographically or you serve many static assets, a CDN helps even at small scale, and many offer free or inexpensive tiers. Many hosting platforms include CDN delivery by default.

Can a CDN cache dynamic content?

Yes, if responses are the same for many users and you define appropriate TTLs and cache keys. Personalized content usually shouldn't be cached at the edge, though edge compute can assemble personalized pages from cached fragments.

What is an origin shield?

A mid-tier cache between edge locations and your origin. Misses from many edges consolidate at the shield, which reduces duplicate requests to the origin and improves hit ratios.

How does a CDN help with DDoS attacks?

A CDN's large, distributed capacity absorbs volumetric attacks, and its filtering (WAF, rate limiting, bot detection) blocks malicious traffic before it reaches your origin servers (rate limiting algorithms).