CDN: how a content delivery network works and whether your site needs one

A CDN (Content Delivery Network) is a network of servers around the world that store copies of your site's files and pages and serve them to users from the nearest node. It speeds up loading, offloads your main server and protects against some attacks. Almost every public site needs a CDN at least for static assets: images, scripts and stylesheets.

Here is how a CDN works, what can be cached, how to manage the cache and the most common mistakes.

How does a CDN work?

When a user requests a file, the request reaches the nearest CDN node. If the node has a copy, it serves it straight away. If not, it fetches the file from your server (the origin), stores a copy and serves it. Subsequent users in that region get the file from the cache.

What this gives you:

• lower latency — data travels hundreds of kilometres instead of thousands;
• less load — the origin serves a file once instead of to every visitor;
• resilience to spikes — CDN nodes absorb a rush of users;
• protection — malicious traffic filtering and hiding the origin's address;
• optimisation — compression, modern image formats and HTTP/2–HTTP/3 out of the box.

What can be cached in a CDN?

Cache everything that is the same for every user: static files, images, public pages and API responses without personal data. Personal pages — cart, account, checkout — are never cached.

Content type	Cache	Duration
JS and CSS with a hash in the file name	Yes	A year
Images and fonts	Yes	Months
Public pages, articles, catalogue	Yes, carefully	Minutes to hours
Public API responses	Sometimes	Seconds to minutes
Cart, account, checkout	No	—

On image optimisation see website images, and on caching at other layers, caching web applications.

Photo: Unsplash

How do you manage the cache?

The cache is controlled by HTTP headers your server sends: they tell the CDN and the browser whether a response can be stored and for how long. For static files, putting a content hash in the file name lets you cache forever, while a new version gets a new name.

# Hashed static files — cache for a year
location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# Public pages — CDN keeps 10 minutes, the browser always revalidates
location /blog/ {
    add_header Cache-Control "public, max-age=0, s-maxage=600, stale-while-revalidate=60";
}

# Account area — never cache anywhere
location /account/ {
    add_header Cache-Control "private, no-store";
}

Rules:

1. Set different durations for static files, pages and APIs.
2. Use stale-while-revalidate so users never wait for the cache to refresh.
3. Purge specific URLs when content changes, not the whole cache.
4. Account for cookies and headers the response depends on, or different users will get the same version.

What mistakes are made when setting up a CDN?

The most dangerous mistake is caching pages with personal data: one user sees someone else's account. Another common problem is leaving the origin directly reachable, so attackers bypass the CDN's protection.

• pages that depend on cookies or authentication get cached;
• after a release users get old scripts because files have no hash in their names;
• the origin is open to everyone rather than only to CDN nodes;
• purging the whole cache on every change causes load spikes on the origin;
• compression and HTTP/2 are not enabled even though the CDN supports them.

How do you measure the CDN's effect?

Measure the share of requests served from cache, page load times from different regions and the load on the origin. A good cache hit ratio for static files is above 90%.

• check the CDN's cache hit ratio report;
• compare speed metrics before and after — see Core Web Vitals;
• inspect response headers: CDNs usually say whether a response came from cache;
• watch the origin's egress traffic — it should drop noticeably.

On spreading load across servers, see load balancing.

In short

• A CDN serves copies of content from the node nearest the user.
• It speeds up the site, offloads the server and protects against some attacks.
• Cache static files for long, public pages briefly and personal data never.
• Manage the cache with Cache-Control headers and hashed file names.
• Close direct access to the origin and track the cache hit ratio.