CDN Content Delivery: What It Actually Does for Your Bill and Your Latency

A CDN is a rented cache with a global footprint: it stores copies of your files in data centres near your readers so the request never has to cross an ocean to reach your origin.

That is the whole idea. Everything else on a CDN product page is packaging around it.

The interesting question is not what a CDN is. It is which of your problems a CDN actually solves, and which ones it quietly makes harder to see. A page that is slow because the origin takes 900ms to render HTML does not get faster because you put a cache in front of it. A page that gets expensive because you serve video from a bandwidth-metered origin does get cheaper. Knowing which one you have is the difference between a useful change and an extra bill.

What a CDN is actually doing
Static content caches, dynamic content mostly does not
The bandwidth arithmetic nobody does before signing up
Cache hit ratio is the only metric worth watching
When a CDN is the wrong fix
The operational cost people forget
How this fits the rest of the stack
FAQ

What a CDN is actually doing

A request for a logo normally travels from the reader’s browser to your origin server, wherever that is. If your origin is in Frankfurt and the reader is in Sydney, that round trip is real physics: roughly 250ms before your server has even read the request.

A CDN puts a caching proxy in a point of presence near Sydney. The first Sydney reader still pays the long trip, because the edge has nothing cached. Every reader after that gets the file from a machine a few milliseconds away, and the origin never hears about them.

Three things follow from that, and they are the three reasons anyone buys a CDN:

Latency drops for cacheable assets, because the distance drops.
Origin load drops, because the edge absorbs the repeat requests.
Origin bandwidth drops, which matters if your host meters it.

Notice what is not on that list. Your server-rendered HTML does not get faster. Your database queries do not get faster. Your first byte on an uncached, personalised page is exactly as slow as it was yesterday, plus one extra hop.

Static content caches, dynamic content mostly does not

The split that matters is not static-versus-dynamic as marketing pages define it. It is whether two different readers can be served the same bytes.

A logo, a stylesheet, a hashed JavaScript bundle, a product photo, a downloadable PDF: same bytes for everyone, cacheable for a year. A dashboard showing the reader’s own invoices: different bytes per reader, cacheable for nobody. A blog post that changes twice a year is the interesting middle, identical for everyone but you want the ability to change it.

That middle case is what cache headers are for. The pattern that works:

# Hashed build assets: the filename changes when the content does.
Cache-Control: public, max-age=31536000, immutable

# HTML you want to be able to update:
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400

The second one says: browsers, always revalidate; edge, hold it for five minutes; and if the origin is down or slow, serve the stale copy for up to a day rather than showing an error. That last clause has saved more weekends than any status page.

The bandwidth arithmetic nobody does before signing up

This is where a CDN either pays for itself immediately or costs you money for nothing.

Work out your actual egress. Take your average page weight, multiply by monthly page views, and add anything heavy served outside a page load: video, downloads, API responses with large payloads. A 2MB page at 100,000 views a month is roughly 200GB. A 300KB page at the same traffic is 30GB.

Now compare that against what your origin charges. Some hosts include a bandwidth allowance and bill overage per gigabyte. Some meter every byte. On RunxBuild, static sites include 120GB of bandwidth and then bill $0.10/GB, which means the 300KB site never sees a bandwidth line at all and the 2MB one sees about eight dollars.

The honest conclusion for most small sites: a CDN is a latency and resilience purchase, not a cost saving. The saving only shows up once your assets are genuinely heavy or your audience is genuinely global. Model it before you assume it.

Cache hit ratio is the only metric worth watching

Every CDN dashboard shows a dozen graphs. One of them tells you whether the thing is working: the percentage of requests served from the edge without touching your origin.

A hit ratio in the nineties means the cache is doing its job. A hit ratio in the fifties means you are paying for a proxy. The usual causes of a bad ratio, roughly in order of how often they turn out to be the problem:

No cache-control header at all, so the edge applies a conservative default or refuses to cache.
A Set-Cookie on a response that should have been anonymous. Most CDNs will not cache a response carrying a cookie.
Query strings that vary per request, such as analytics parameters, creating a separate cache key for every visitor.
A Vary header on something high-cardinality like User-Agent, which fragments the cache into thousands of near-identical copies.
A TTL so short that entries expire before the next reader arrives.

Fix those in that order. The first two account for most of the gap in practice.

When a CDN is the wrong fix

If your time to first byte is bad because the origin is slow, a CDN adds a hop and hides the problem behind an average. The page feels marginally better for repeat readers and exactly as bad for everyone hitting an uncached path, which is usually the path that matters.

Measure first. If your origin responds in 40ms and the reader waits 800ms, that is distance and you have a CDN problem. If your origin responds in 900ms, that is your application and the CDN will not touch it. Profile the slow query, add the index, cache the expensive render server-side.

The same logic applies to a purely regional audience. A CDN for a business whose readers are all within one country, whose origin is in that country, is buying a solution to a distance problem that does not exist.

The operational cost people forget

A CDN adds a layer between you and your users, and layers have failure modes. You now have two places a request can 404, two sets of headers, two caches to purge, and a certificate story that involves someone else.

Concretely, budget for these:

Purge discipline. Deploying new HTML while the edge holds the old copy is the classic first-week incident. Either hash your asset filenames so purging is unnecessary, or wire a purge into your deploy step.
Origin protection. If your origin IP is still publicly reachable, an attacker can bypass the CDN entirely. Firewall the origin to the CDN ranges or the DDoS protection is decorative.
Header debugging. Learn to read your CDN cache-status header before you need it at 2am. Knowing whether a response was a hit, a miss, expired or bypassed turns a mystery into a five-minute fix.
Certificate ownership. Termination at the edge means the edge holds a certificate for your domain. That is fine and normal, but you should know it is true.

How this fits the rest of the stack

A CDN is one line item in a stack that also has compute, a database, storage and egress, and the sensible time to look at all of them together is before the traffic arrives rather than after the invoice does. The RunxBuild hosting calculator puts those numbers side by side so the bandwidth figure is a decision rather than a surprise. On RunxBuild, static sites include 120GB of bandwidth before the per-gigabyte rate applies, which for most sites is the difference between a CDN being a performance purchase and a cost one.

Useful related references:

FAQ

Does a CDN make my website faster?

For cacheable assets served to distant readers, yes, often dramatically. For server-rendered pages that are slow because the origin is slow, no. Measure your origin response time first: if it is fast and the reader still waits, the delay is distance and a CDN helps. If the origin itself is slow, fix that instead.

What is a good cache hit ratio?

Above 90% for a static-heavy site is healthy. Between 50% and 80% usually means missing cache-control headers, cookies on anonymous responses, or query strings fragmenting the cache key. Below 50% means the CDN is acting as a proxy rather than a cache.

Do I still need a CDN if my host includes bandwidth?

It depends what you are buying. An included bandwidth allowance removes the cost argument, but not the latency one. If your readers are concentrated in one region near your origin, you may not need a CDN at all. If they are spread across continents, the distance argument stands regardless of billing.

Can a CDN cache dynamic or personalised pages?

Only if you split the response. The standard approach is to cache the shared shell at the edge and fetch the personalised fragment separately from the origin, or to use a short s-maxage with stale-while-revalidate for pages that are the same for everyone but change occasionally. Never cache a response that carries a Set-Cookie header.

Does a CDN protect against DDoS attacks?

Partly, and only if configured properly. The edge absorbs volumetric traffic before it reaches your origin, which is genuinely useful. But if your origin IP is publicly reachable, an attacker can address it directly and bypass the CDN entirely. Firewalling the origin to the CDN address ranges is what makes the protection real.