Sign up for a CDN, flip a CNAME record, and your site gets faster. That is the pitch, and for a lot of sites it is even true. But “a lot” is not “all,” and the gap between the two is where teams burn money and add a layer of caching complexity for a speedup nobody can measure. A content delivery network is not a magic accelerator — it is a very specific tool that attacks two very specific costs: the physical distance between your server and your visitors, and the repeated work your origin does serving the same bytes over and over. If your site pays those costs, a CDN pays for itself quickly. If it doesn’t, you are adding an invalidation problem to a site that didn’t have one.
This piece walks through the concrete signals that a CDN will genuinely speed up your site, the situations where it barely moves the needle, and the configuration mistakes that quietly cancel the benefit you signed up for.
What a CDN actually changes about a page load
Strip away the marketing and a CDN does three things, all of them well documented in web.dev’s engineering guide to content delivery networks. First, its servers sit physically closer to your users than your origin does, so the round-trip time (RTT) on every request drops. Second, even for content it cannot cache, a CDN terminates the user’s new connection at a nearby edge server and then carries the request to your origin over its own network — often over existing, pre-warmed connections that skip the multi-roundtrip cost of TLS setup and run over routes the CDN has tuned for performance rather than whatever paths the internet’s default BGP routing happens to pick. Third, and most famously, it caches: once an edge server has a copy of your stylesheet or product image, requests for it never touch your origin at all.
That third mechanism is the one people mean when they say “CDN,” and it works on a pull model. As the web.dev guide describes, the first request for a resource misses the cache, gets fetched from your origin, and the response is stored at the edge — “origin pull.” Every subsequent request from that region is served locally until the resource expires, gets evicted to make room for hotter content, or is explicitly purged.
The payoff shows up first in Time to First Byte, and TTFB feeds directly into Largest Contentful Paint — the Core Web Vital that measures when the main content of your page becomes visible. A CDN improves LCP from two directions at once: it delivers the HTML document sooner, and it delivers the images, fonts, and scripts that render the LCP element sooner.
Signal one: your users are not where your server is
This is the clearest yes. AWS’s own explainer is blunt about the physics: when a user is located far from the server, “it will take a long time to load a large file, such as a video or website image,” because every request and response has to cross that distance — twice, since the communication is two-way. A single origin in Frankfurt serving visitors in São Paulo, Mumbai, and Sydney is paying 200-plus milliseconds of round-trip tax on every uncached request, multiplied across every connection the page opens.
Check your analytics before you check CDN pricing pages. If 90 percent of your traffic comes from the same country your VPS lives in, geography is not your problem and the “closer to users” benefit collapses to nearly nothing. If your audience spans three continents, distance is probably the single largest line item in your load time, and a CDN attacks it directly.
Signal two: the same bytes get requested over and over
Caching only helps when there is repetition to exploit. Static assets — images, video, fonts, versioned JavaScript bundles — are the textbook case. They change rarely, they are identical for every visitor, and the web.dev guidance is to cache them with a long time-to-live of six months to a year. A product photo requested 40,000 times a day from one origin server becomes a resource your origin serves once per CDN region and then forgets about.
The less obvious win is what the guide calls caching dynamic content for very short windows. A store homepage or a popular API response that changes frequently can still be cached for five seconds — and during a traffic spike, a five-second TTL means your origin renders that page once every five seconds instead of hundreds of times, with barely any freshness cost. This is the mechanism behind the claim that CDNs help you survive traffic spikes: the cache absorbs the repetition your origin would otherwise eat.
What genuinely cannot be cached is anything private. Responses carrying a Cache-Control: private or no-store header — logged-in dashboards, carts, account pages — are per-user by definition, and a shared cache must not store them. A site that is almost entirely personalized, gated content gets far less from the caching layer than its traffic volume suggests. It can still benefit from the connection-level optimizations, but the headline “offload 95% of requests” outcome is off the table.
Signal three: your origin is the bottleneck under load
If your server holds up fine at peak traffic, offloading requests buys you resilience but not visible speed. If your TTFB climbs during busy hours because the origin is saturated, a CDN delivers a speedup that has nothing to do with geography: every request served from the edge is CPU, bandwidth, and connection capacity your origin gets back. AWS lists reduced bandwidth consumption and lower load on the web server among the primary reasons CDNs exist, and it is often the honest reason mid-sized sites adopt one — the speed win is a side effect of no longer running the origin hot.
Where a CDN won’t save you
It is worth being precise about the failure cases, because they are common.
Slow backend, fast network. If your page takes 1.8 seconds because of an unindexed database query or a bloated server-side render, a CDN edge in the same city as your user will faithfully deliver that 1.8-second response with excellent latency. Caching the final HTML can mask this for anonymous traffic, but for logged-in or personalized pages the CDN is just a fast pipe to a slow kitchen.
Client-side weight. A page shipping four megabytes of JavaScript is slow on the user’s device, not on the wire. The CDN gets the bundle there sooner; the main thread still chokes parsing it. No amount of edge infrastructure fixes a frontend problem.
Local audience, capable server. A regional business with a nearby, underutilized server is already close to optimal. Adding a CDN introduces a cache layer to configure and invalidate for single-digit-millisecond gains.
Misconfiguration that silently disables caching. This is the big one. A CDN with a low cache hit ratio is mostly an expensive proxy. Stray Set-Cookie headers on static assets, unnecessarily varied cache keys, and unsorted query strings all fragment the cache into copies that never get reused. And platform defaults matter more than people assume: Cloudflare’s default cache behavior documentation shows that out of the box it caches based on file extension — static asset types — while HTML and API responses pass through uncached unless you write explicit cache rules. Plenty of teams “have a CDN” that is caching their logo and nothing else.
The invalidation trade you are signing up for
The cost of a CDN is not the monthly bill; it is that “deploy” no longer means “users see the new version.” You now manage TTLs, and you inherit purging — explicitly ejecting stale content from edge caches, which the web.dev guide notes is critical when content must be retracted, such as correcting a pricing error that is now cached in 200 cities.
Mature setups turn this from a chore into a strategy. With near-instant purging, you can cache aggressively with long TTLs and purge on every update — the pattern known as “hold-till-told” caching. At scale, cache tags (Cloudflare exposes this as purge by cache-tags) let you label every page containing, say, your site footer, and purge exactly that set when the footer changes. These are powerful tools, but they are tools you now have to hold correctly. A team that is not ready to think about invalidation will eventually serve something stale at the worst possible moment.
A 15-minute decision test
Before committing, run three checks with data you already have:
- Measure TTFB from where your users are, not from your desk. Use any multi-region testing tool against your slowest-served geography. If remote TTFB is several multiples of local TTFB, distance is your problem — signal one confirmed.
- Read a week of access logs. What fraction of requests are cacheable public assets versus private, per-user responses? High repetition of public content means the cache will earn its keep.
- Compare peak-hour and quiet-hour response times from the same location. If they diverge, your origin is load-bound and offloading will show up as real speed.
Two or three yeses and a CDN is one of the cheapest performance wins available — the setup, per web.dev, can be as simple as pointing your www CNAME at the provider and then spending your effort where it actually matters: getting the cache hit ratio up. Zero or one yes, and you will get more user-visible speed from fixing the slow query, shrinking the bundle, or compressing the images. The CDN will still be there when your traffic map outgrows your server’s zip code — and that, not the marketing, is the right moment to buy one.
