Every CDN vendor's homepage says roughly the same thing: cache content closer to the user, reduce latency, make pages load faster. That's true, but it undersells what's actually happening architecturally. A correctly configured edge cache isn't just a speed trick — it changes how much load your origin server has to absorb, how your site behaves during a traffic spike, and how exposed you are to a single point of failure.
The mechanism, briefly
A CDN is a distributed network of edge servers, or points of presence (PoPs), positioned around the world. When content is available at the nearest PoP, that's a cache hit, and the response never has to travel back to your origin server. When it isn't cached, that's a cache miss, and the request falls through to the origin — adding latency and, more importantly, adding load to a server that was supposed to be protected from that traffic in the first place.
The ratio between those two outcomes — your cache hit ratio — is the single number that determines whether your CDN is doing real work or just adding a network hop. A well-tuned setup targets 90%-or-higher hit rates for static-like content such as images, CSS, JS, and fonts, with static cache-hit responses landing in the 50-150ms range globally and under 100ms in primary markets.
Why origin load matters more than people think
The latency number gets all the attention, but the origin-load reduction is arguably the more important effect for a growing site. A cache-first pattern — where an edge function reads from a fast key-value store and only falls through to the origin database on a miss — commonly cuts origin load by more than 90% for popular endpoints. That's not just a performance win; it's the difference between your database surviving a traffic spike and falling over during one.
This is the part that's easy to miss when a team thinks of "adding a CDN" as a checkbox: the real benefit shows up during the worst moment, not the average one. A launch, a promotional spike, or a sudden surge in referral traffic is exactly when an unprotected origin server is most likely to buckle — and exactly when a high cache-hit ratio matters most.
The TTFB number that's easy to fix and usually ignored
Time to First Byte (TTFB) — how long it takes the first byte of a response to arrive — is frequently dominated by hosting choice rather than code. Moving from shared hosting to a properly configured managed host or edge platform commonly delivers a 60-80% reduction in TTFB on its own, before any application-level optimization happens. If a site's TTFB consistently exceeds 300-400ms from major markets, that's almost always a hosting or CDN configuration problem rather than something to fix in JavaScript.
Stale-while-revalidate: serving fast without serving stale
One pattern worth understanding specifically because it resolves the classic tension between speed and freshness is stale-while-revalidate. Instead of choosing between "always fast but possibly outdated" and "always fresh but possibly slow," the edge serves the cached response immediately and revalidates it against the origin in the background. The visitor gets the fast response; the cache quietly updates for the next one. Cloudflare's own KV store, for example, propagates writes to its global network of edge locations within about 60 seconds, which is fast enough that most content feels current without ever making a visitor wait on a cache miss.
The number everyone cites, with the right amount of caution
It's worth addressing the most repeated statistic in this space directly: the claim that Amazon found every 100 milliseconds of latency cost 1% in sales. This figure is widely attributed to a 2006-era internal Amazon experiment, surfaced publicly through a former Amazon engineer's blog post and a conference talk rather than a formally published company study. The direction of the finding — that small latency increases measurably hurt conversion — has since been echoed across many independent, better-documented studies. But the specific "1% per 100ms" figure itself should be treated as a widely cited estimate from a single internal source rather than an audited, reproducible benchmark. Use it to make the directional case for performance investment, not as a precise multiplier for your own revenue model.
What this means for an architecture decision
The practical takeaway isn't "add a CDN" — almost everyone already has one. It's choosing cache rules deliberately: set generous Cache-Control headers with stale-while-revalidate for anything that doesn't need to be instantly fresh, push read-heavy API responses into an edge key-value store instead of hitting the origin database on every request, and treat your cache hit ratio as a metric worth dashboarding, not a CDN vendor's problem to silently solve. The latency improvement is the visible part. The origin protection is the part that keeps the site up.
Frequently asked questions
A traditional CDN mainly caches static files like images, CSS, and JavaScript at edge servers close to visitors. Edge caching is the broader practice of storing content, including full dynamic HTML pages, at those same edge locations so more of the response can be served without contacting the origin at all. Every edge cache setup relies on CDN infrastructure, but not every CDN setup uses full edge caching.
Static assets that look the same for every visitor — images, CSS, JavaScript, fonts, and most blog or marketing pages — are ideal candidates and can usually be cached for hours or days. Personalized or authenticated content, such as shopping carts, checkout pages, account dashboards, and password reset flows, should bypass the cache entirely, since caching them risks one visitor seeing another visitor's data.
TTL (time to live) is how long an edge server keeps a cached response before checking the origin again. Shorter TTLs (minutes) suit frequently changing content like product prices or search results; longer TTLs (hours to a day) suit blog posts and static pages that rarely change. A common practice is starting with shorter TTLs when first enabling edge caching, then extending them once you're confident the configuration is correct.
Yes, using a hybrid approach: cache the static page structure and shell at the edge, then load personalized elements like recommendations or account details client-side with JavaScript after the cached page renders. This gets you the speed benefit of edge caching for the bulk of the page without serving one visitor's personal data to another.
For static-like content (images, CSS, JS, fonts), a well-tuned setup typically targets a 90% or higher cache hit ratio, meaning fewer than 1 in 10 requests for that content ever reaches the origin server. A consistently low hit ratio usually points to a caching-rules misconfiguration rather than content that's inherently uncacheable.
The underlying finding is real but informal: it traces back to a 2006-era internal Amazon experiment that surfaced publicly through a former engineer's blog post and conference talk, not a peer-reviewed or officially published Amazon study. The direction of the finding — that small latency increases hurt conversion — has been echoed by many independently documented studies since, so it's reasonable to cite as directional evidence, just not as a precise, audited multiplier for your own site.
