How a CDN Makes Things Fast — From Cache Hits to Dynamic Content

Infrastructure Performance Networking Backend
4 min read

What a CDN is, in lay terms, was covered in the cache & CDN explainer. This post is the practitioner’s angle on the same topic: exactly which part of the request time a CDN removes, what determines hit rate, and how configuration mistakes quietly turn a CDN into decoration.

What a CDN cuts — distance, in the end #

Reusing the network post’s conclusion: perceived speed for small requests is RTT × round-trip count, and RTT’s floor is physical distance. A user in Seoul fetching content from a US server pays round trips on the order of 130ms. A CDN shrinks the distance: edge servers around the world hold copies and answer from nearby, bringing the RTT for that request down to single-digit milliseconds.

The effect multiplies by round-trip count: the two round trips for the TCP and TLS handshakes, plus the request itself, all happen over the short distance, so time-to-first-byte (TTFB) drops wholesale. From the origin’s perspective, traffic absorbed at the edge also means less load and lower transfer costs.

Hit rate — the CDN’s performance is this one number #

If the edge has the copy (hit): milliseconds. If not (miss): the original trip to the origin plus a little overhead. So a CDN’s effective performance is its hit rate — 95% and 60% are different products. Two things determine it.

First, cache policy — the server declares it in headers. CDNs follow the origin’s Cache-Control by default.

Cache-Control examples 
# static assets with build hashes — cache for a year, declared immutable
Cache-Control: public, max-age=31536000, immutable

# HTML — briefly at the edge, always revalidated by browsers
Cache-Control: public, max-age=0, s-maxage=60

# personalized responses — no shared caching
Cache-Control: private, no-store

The standard strategy fits in those three lines. Hash-named assets can be cached forever safely (new content means a new filename); HTML gets a short edge cache (s-maxage) that shields the origin while keeping updates fast; personalized responses stay out of shared caches. Declare nothing, and you’ve entrusted your fate to the CDN’s defaults.

Second, the cache key — what counts as “the same request.” The edge reuses a copy only when the cache key (the URL, by default) matches. The classic hit-rate killers are:

  • Irrelevant query parameters — tracking params (utm_* and friends) make the same content cache as separate entries per URL. The fix is excluding irrelevant params from the cache key.
  • Overbroad Vary headers — Vary: Cookie effectively disables caching, since every user’s cookies differ.
  • Session cookies on every response — many CDNs refuse to cache responses carrying Set-Cookie, static assets included. The classic fix is serving assets from a cookieless domain or path.

Invalidation — caching’s one hard problem #

“Cache long and updates lag; cache short and there’s no benefit” resolves differently per content type. Hash-named assets need no invalidation (new filename = new cache entry). Fixed-URL content (HTML, APIs) runs short s-maxage plus purges on deploy. stale-while-revalidate — serve the expired copy now, refresh behind the scenes — erases the miss penalty of short caches and is the practical middle ground. With tag-based purging (invalidate just the URLs touching one post), even API responses become cacheable.

Beware the habit of full purges in the deploy routine: every deploy resets hit rate to zero and the origin takes the full brunt right after each release. Purge narrowly, hash your assets — with those two rules, full purges are rarely needed.

What can’t be cached — and how the CDN still helps #

Even for uncacheable traffic — logged-in users’ API responses — routing through the CDN often pays. The reason, again, is round trips.

  • TLS terminates at the edge — the user’s handshake round trips happen over the short distance.
  • An optimized edge-to-origin leg — CDNs keep pre-warmed, reused connections to the origin and route over their backbone, often beating a user’s raw path across the internet.
  • Protocols and compression — modern protocols (HTTP/2, HTTP/3) and compression (brotli) are handled at the edge, upgrading the user-facing experience even when the origin is dated.

The working mental model, then, isn’t “a static file distribution tool” but “a layer that pulls the user’s round trips to the edge.”

Summary #

  • A CDN’s effect is shrinking distance to cut the RTT × round-trip product; TTFB, origin load, and transfer costs drop together.
  • Effective performance is hit rate, and hit rate is decided by Cache-Control declarations and cache key design. Putting hit rate on a dashboard is step one.
  • The base strategy: hash-named assets cached forever, HTML/API on short s-maxage with narrow purges, personalized responses private.
  • The three classic hit-rate killers: tracking parameters, Vary: Cookie, and session cookies on assets.
  • Even uncacheable traffic benefits from edge TLS termination, connection reuse, and modern protocols.
X