CDNs and Caching: The Cheapest Performance You Can Buy

What you get

• Latency. A response from 50 km away arrives far sooner than one from another continent.
• Lower egress cost. CDN egress is priced below origin egress on most platforms, and cached hits never touch the origin at all.
• Less origin load. A high cache hit ratio means the origin serves a fraction of requests.
• Absorption of traffic spikes, including abusive ones. See DDoS and abuse protection.
• TLS termination at the edge, which shortens the handshake round trip.
• Compression and modern protocols applied without changing the origin.

Cache headers, which are the whole configuration

Two rules cover most cases. Fingerprint asset filenames and cache them for a year. Never cache a response containing anything specific to one user.

Use Vary sparingly. Each varied header multiplies the number of cached copies and reduces hit ratio.

Caching dynamic responses

Dynamic does not mean uncacheable. A product listing that changes twice a day can be cached for minutes, and s-maxage with stale-while-revalidate makes that nearly invisible to users.

1. Identify responses identical for all anonymous users.
2. Cache them at the edge with a short TTL.
3. Add stale-while-revalidate so a refresh never blocks a request.
4. Purge explicitly when content changes, rather than relying only on expiry.
5. Keep authenticated responses out of the shared cache entirely.

Even a thirty-second cache on a busy page removes the great majority of origin requests.

The cache key

Everything the CDN includes in the key creates a separate cached copy. Getting this wrong is the usual cause of a disappointing hit ratio.

• Ignore query parameters you do not use — tracking parameters in particular, which otherwise split the cache endlessly and enable cache-busting attacks.
• Normalise the path, so trailing slashes and case do not create duplicates.
• Do not include cookies in the key unless they genuinely change the response.
• Where content differs by country or device, vary deliberately and accept the multiplication.

Caching layers beyond the edge

1. Browser cache — free, closest to the user, controlled by max-age.
2. CDN edge cache — shared across users, controlled by s-maxage.
3. Reverse proxy cache on your own server — catches what the CDN did not.
4. Application cache — Redis or Memcached for computed results and query output.
5. Database query cache — for repeated expensive queries.

Each layer that absorbs a request saves everything below it. The most valuable optimisation is almost always the one furthest from the database.

Choosing a CDN

Every hyperscaler has one, integrated with their storage and load balancers. DigitalOcean includes CDN with Spaces. OVHcloud and others offer their own. Independent CDNs compete on features, pricing model and point-of-presence coverage.

Selection criteria that matter: presence near your users, price per gigabyte at your volume, purge speed, and whether the caching rules you need are expressible. For most sites, the provider’s own CDN is the simplest sound choice.

Common questions

Where to go next

See egress costs and reverse proxy basics.