CDNs: what they fix, and what they do not

A content delivery network keeps copies of your responses at locations near your users and serves them from there. For most sites it is the single highest-return infrastructure change available: it reduces latency, reduces origin load, and reduces egress cost simultaneously.

It is also frequently deployed in a configuration that caches almost nothing, at which point it is an extra hop that provides none of those benefits.

What it genuinely fixes

Latency for static assets. Images, stylesheets, scripts and fonts served from a nearby edge rather than an origin on another continent. This is usually the largest perceived speed improvement available for a content-heavy site.

Origin load. Requests served from cache never reach your servers, which means the origin can be considerably smaller than raw traffic figures suggest.

Egress cost. Traffic from the edge is typically priced well below origin egress, and cache hits generate no origin egress at all. For media-heavy sites this alone frequently justifies the change.

Traffic spikes. A cached response can be served to a very large number of people without the origin noticing.

A place to put edge logic. TLS termination, security headers, redirects, request filtering and basic rate limiting, all applied before traffic reaches your infrastructure.

What it does not fix

Slow dynamic responses. A personalised, uncacheable page is fetched from the origin every time. If your application takes eight hundred milliseconds to generate a page, a CDN adds a hop and the page still takes eight hundred milliseconds.

Database performance. Entirely unaffected.

Write traffic. Form submissions, API writes and uploads go to the origin.

Bad architecture. A page making forty sequential requests is slow from anywhere. Fewer round trips matters more than shorter ones.

Availability, unless configured for it. By default, origin down means site down. Serving stale content when the origin is unreachable is usually available but often not enabled, and it is one of the more valuable options on offer.

Why CDNs so often cache nothing

Almost always because of cache headers, and there are three recurring causes.

No cache headers at all. Without explicit directives many CDNs will not cache, or will cache for a very short default. Set Cache-Control deliberately on every response.

Cookies on static assets. A response carrying a Set-Cookie header is treated as personalised and not cached. Serving static files from a path that never sets cookies, or stripping the header at the edge, fixes this immediately and is a very common quick win.

Query strings creating cache fragmentation. If the cache key includes the full query string, then tracking parameters appended by campaigns turn one cacheable asset into thousands of distinct cache entries, each with its own miss. Normalise the cache key to ignore parameters that do not change the response.

The diagnostic is simple: look at the cache status header on responses in your browser’s network panel. A high proportion of misses on static assets means one of the above.

Cache the dynamic parts too, carefully

Static assets are the easy half. Real gains often sit in cacheable dynamic content.

Short time-to-live caching of a few seconds on a busy endpoint absorbs an enormous share of load during a spike while keeping content essentially fresh.

Stale-while-revalidate serves the cached copy immediately and refreshes in the background, which removes the latency penalty of expiry entirely.

Vary carefully. Caching a response that varies by user without including the distinguishing factor in the cache key serves one user’s content to another. This is the failure mode worth being most careful about, and it argues for caching only responses you have deliberately confirmed are identical for everyone.

Purge on change rather than relying on short expiry. Long expiry with explicit invalidation gives better hit rates than short expiry with none.

Versioned filenames, so assets can cache forever

The standard technique for static assets is to include a content hash in the filename. When the file changes, the name changes, so a new URL is requested.

That allows a very long cache lifetime on the asset itself, because it can never be stale: a changed file is a different URL. Only the HTML referencing it needs a short lifetime.

Any modern build tool does this by default. If your assets are served with short cache lifetimes because “they might change”, versioned filenames is the fix.

Deciding whether you need one

If you serve images, video or downloads to any meaningful audience, yes, and it will probably pay for itself in egress alone.

If your users are geographically spread, yes, for latency.

If your traffic is spiky, yes, for absorbing spikes.

If you serve a small internal application to users in one office near your origin, with no static content of consequence, the benefit is marginal and the added complexity may not be worth it.

Before you turn it on

Measure your current cache-hit ratio if anything is caching today, and your current origin egress. Then set explicit cache headers, remove cookies from static asset paths, adopt versioned filenames, and enable stale-if-error.

Doing those four things first means the CDN starts useful rather than starting as a hop that caches nothing while you work out why.

The same reasoning applies across providers. The catalogue of cloud accounts sets out where each one fits, if you are still deciding which to build on.

For the vendor’s own reference on the services involved here, see the OVHcloud documentation.

If you would rather test this than read about it, our OVHcloud accounts come in four configurations across a wide product range, and the cloud account catalogue lists every provider we carry.

Questions people ask