What is a CDN and how does it make sites faster?
A content delivery network puts copies of your files close to users. Here is how it works, how to control it with headers, and what it cannot cache.
A CDN (content delivery network) is a set of servers spread across many cities. When someone requests your image or script, the nearest server answers instead of your single origin server far away.
Why it helps
- Lower latency: distance matters. A user in Dhaka reaching a server in Europe waits for a long round trip. A nearby edge server is much quicker.
- Less load on your origin: most requests never reach it.
- Spike and attack protection: traffic is absorbed at the edge. Many CDNs also add DDoS and bot filtering.
How it works
- The user requests a file. DNS sends them to the nearest edge.
- If the edge has it (cache hit), it answers immediately.
- If not (cache miss), it fetches from your origin, stores a copy and answers.
- Later users near that edge get the cached copy.
You control it with headers
Cache-Control: public, max-age=31536000, immutable tells caches to keep a file for a year. That suits files with a hash in the name, such as app.3fa9c.js. For pages that change, use a short time or no-store. When you must clear a file early, use the CDN's purge feature.
What to put on a CDN
- Images, video, fonts, CSS and JavaScript: always.
- Public HTML that changes slowly: yes, with a short TTL.
- Personalised or logged-in pages and API responses with private data: not cached, or only with care.
Watch out
Caching the wrong thing can show one user another user's page. Never cache responses that depend on cookies unless the cache key accounts for it.
Takeaway: put static files behind a CDN, set long cache times with versioned file names, and keep private responses out of shared caches.
Part 6 of 15 in the System Design series. Previous: Caching strategies: cache-aside, write-through and write-back.
