Skip to content
FLAVIO COPES
flaviocopes.com
2026

What is a CDN?

By

Learn how a CDN serves cached content from edge locations, how cache misses reach the origin, and how TTLs, cache keys, and purges control freshness.

~~~

A CDN is a Content Delivery Network.

It is a distributed network of edge servers that can serve content closer to users.

The shorter network path can reduce latency. Caching at the edge can also reduce work and bandwidth at the origin server.

How a CDN request works

A typical request follows these steps:

  1. DNS or network routing sends the user to a nearby CDN location.
  2. The CDN builds a cache key from the request.
  3. If a fresh matching response exists, the CDN returns it.
  4. Otherwise, the CDN requests the resource from the origin.
  5. The CDN can store the response and return it to the user.

The first request at one location is a cache miss. Later matching requests can be cache hits.

A CDN does not guarantee that every request avoids the origin. A response may be expired, uncacheable, purged, personalized, or missing from that location.

What can a CDN cache?

CDNs commonly cache:

Many CDNs cache familiar static file extensions by default. HTML and API responses often need explicit rules or cache headers.

Dynamic does not always mean uncacheable. A server can generate a response once and let the CDN reuse it for an appropriate amount of time.

Private account pages and personalized responses need more care.

Cache freshness

The origin can describe freshness with HTTP headers:

Cache-Control: public, max-age=300

This says a shared cache may reuse the response for five minutes.

Some CDNs understand shared-cache directives such as s-maxage:

Cache-Control: public, max-age=60, s-maxage=3600

Here a browser can cache for one minute, while a shared cache can cache for one hour.

Exact behavior depends on the CDN configuration. A CDN can override origin headers with edge rules.

no-store tells caches not to store a response:

Cache-Control: no-store

Do not make sensitive or user-specific responses public unless the cache key safely separates every variant.

Cache keys

The cache key decides which requests share one cached response.

It usually includes the scheme, host, path, and query string. A CDN can be configured to include or ignore selected headers, cookies, and query parameters.

A bad cache key can cause two opposite problems:

The second problem is a security issue.

Use the Vary response header when representation selection depends on a request header:

Vary: Accept-Encoding

CDN support and configuration still need to agree with the origin’s intent.

Updating cached content

Cached content does not automatically change the instant the origin changes.

You have three common options:

Versioned asset names work well:

/assets/app.a84f2c.js

When the content changes, the URL changes. Old pages can keep using the old file, while new pages request the new one.

Use long cache lifetimes only when URLs change with content or you have a reliable invalidation plan.

CDN benefits

A well-configured CDN can provide:

These features vary by provider and plan.

A CDN does not make an application secure by itself. The origin still needs authentication, authorization, updates, backups, and correct HTTP headers.

Protect the origin so attackers cannot bypass CDN controls by connecting to it directly.

When a CDN helps

A CDN helps most when users are spread across regions or when many users request the same content.

It helps less when every response is private, unique, and generated near the user already.

Measure the result. Check latency, cache-hit ratio, origin traffic, and how quickly updates reach users.

If you’re curious how much bandwidth your site consumes, the bandwidth calculator estimates it from page views and page weight.

For concrete cache behavior, see Cloudflare’s documentation on default cache behavior and origin Cache-Control, plus Amazon CloudFront’s guide to cache behavior settings.

~~~

Related posts about network: