A global network of edge servers that caches your content and serves it from a location CLOSE to each user — so your one VPS can reach the whole world.
← / → to navigate · EN/VI switch below
Content Delivery Network: a global network of edge servers that caches and serves your content from a location CLOSE to each user.
Hundreds of data centers (the 'edge nodes') spread across continents. Not one server — a network.
Servers at the 'edge' of the internet — the nodes closest to users, as opposed to your single origin server (your VPS).
It stores copies of your static assets — images, CSS, JS, fonts — on those edge nodes.
Each user's browser fetches files from the nearest edge node — not from your server across the ocean.
The difference a CDN makes, in one picture.
Every user, wherever on Earth, downloads your files from your single origin VPS. Hanoi → Singapore → Frankfurt… long hops, slow pages.
Your one server does all the work — and its bandwidth bill grows.
The same files already sit on edge nodes near each user. Hanoi fetches from a node in Asia — a short hop, fast pages.
Your origin only works when a node needs to refill its cache.
Static = the file doesn't change per user: images, CSS, JS, fonts, videos. (Dynamic API responses usually still go to your origin.)
Images, CSS, JS, fonts get copied to edge nodes near users — the CDN is a giant cache in front of your site.
Bytes travel a shorter distance at lower latency — pages open visibly faster, worldwide.
Your VPS stops sending 10,000 copies of logo.png — the edge nodes do. Less CPU, less bandwidth.
Global users all get a nearby copy; the CDN network also absorbs a lot of attack traffic before it reaches you.
Three reasons, all about distance and load.
Physics: the closer the bytes, the faster they arrive. A CDN puts a copy of your files in every corner of the world.
90%+ of requests are 'give me that image again' — the CDN answers them without touching your VPS. Cheaper, and it scales.
Many nodes means no single point of failure. One origin hiccup or a traffic spike doesn't take your site down.
CNAME, cache miss, cache hit — three words explain a CDN.
The first visitor pays the price; everyone nearby after rides free.
A CNAME record in your DNS makes www.example.com resolve to the CDN's name instead of your VPS's IP.
The nearest edge node doesn't have logo.png yet — so it fetches it from your origin (the VPS) and stores a copy.
Now a copy sits on that node. How long it's kept is decided by TTL / Cache-Control headers.
The next thousand visitors in that region get the file from the node directly — fast, and your origin never hears about it.
Your VPS stays home. The CDN's nodes stand between your files and the whole world.
Hanoi · London · São Paulo
Each browser asks the CDN (your CNAME) for /static/css/main.css — it never asks your VPS directly.
⟶
every request
Hanoi node · London node · São Paulo node …
Copy already here → serve it (HIT, fast). No copy yet → ask the origin, store the copy, then serve (MISS, once per TTL).
⟶
on a miss only — fetch & cache
example.com — nginx + Flask
Serves the true file only when a node misses. After the first pass, it mostly sleeps.
First visitor pays the origin round-trip; the next thousand in that region ride the local copy.
Every edge request ends in exactly one of these.
| First request — MISS | Later requests — HIT | |
|---|---|---|
| Who has the file? | Only the origin (your VPS) | The edge node too |
| What happens | Edge asks the origin, stores a copy | Edge serves its copy directly |
| Latency for the user | Higher — origin round-trip included | Lower — nearest node answers |
| Origin load | Serves the file | 0 — never asked |
The CDN follows two dials you set — it doesn't guess.
A number of seconds the copy may sit on the edge node. TTL 3600 = the node re-checks the origin every hour.
Big TTL for rarely-changing files (logos); small TTL for pages that change often.
The HTTP header your server sends with the file: Cache-Control: public, max-age=31536000 tells every cache — edge and browser — to keep it for a year.
The CDN obeys it; immutable means 'never re-check until expiry'.
The whole 'setup' from your side: one CNAME record. After this, your domain is served by the CDN's network.
# point the site at the CDN instead of the VPS
www.example.com. 3600 IN CNAME example.com.cdn.cloudflare.net.
# the CDN's name resolves to different edge IPs
# per region — that's the 'global network' partCNAME = 'this name is an alias of that name'. The 3600 is the DNS TTL in seconds.
A tiny HTML head: two URLs that would sit on edge nodes around the world.
<head>
<meta charset="utf-8">
<link rel="stylesheet" href="/static/css/main.css">
<script src="/static/js/app.js"></script>
</head>Every request for main.css or app.js can be answered by the nearest node — your VPS never sees most of them.
What your server sends with each file — and what the CDN reads to decide how long to keep it.
HTTP/2 200
Content-Type: text/css
Cache-Control: public, max-age=31536000, immutable
Age: 4320max-age=31536000 = one year of caching. Age = how long this copy has sat on the edge (4320 s ≈ 72 min).
dig shows the domain pointing at the CDN; curl -I shows the headers a cached copy carries.
You'll use one of these three more than 95% of the time — they all do the same core job.
The default choice for small sites: a free tier that includes the CDN and basic DDoS protection. Often all you need.
Popular for very fresh content — its edge can purge (drop) cached copies in seconds when you deploy.
Amazon's CDN — the natural partner when your site already lives on AWS.
A CDN has a deep toolbox. These are real — but not your next step.
Fine-tuning how the edge fetches from your origin (retries, backends, private links). Defaults are fine to start.
Running small scripts ON the edge nodes (rewrites, A/B tests, bot rules). Powerful — and a whole topic of its own.
Per-path TTLs, cache-key tweaks, stale-while-revalidate. You'll reach for these only when a real problem appears.
A CDN is a global cache in front of your site: your files sit near every user, so pages are fast, the origin stays light, and the whole thing is harder to break.
Next: put nginx in front of Flask — and someday, a CDN in front of nginx.