What a CDN actually does (and the small-site case for one)

A CDN — content delivery network — is one of those terms that sounds like infrastructure only big sites need. It is not. At its simplest, a CDN keeps copies of your site's static files (images, scripts, styles, pages) on servers scattered around the world, and serves each visitor from the nearest one instead of from your single origin server. For a slow-loading or internationally-read site, it is often the cheapest large improvement available.

The problem it solves

Without a CDN, every visitor pulls from one place. A reader in Lagos hitting a server in Oregon waits for every request to cross the Atlantic — and the latency in why your website is slow is often exactly this distance, not your code. A CDN puts a copy much closer to that reader, so the slow trans-oceanic trip happens once (origin to CDN) rather than once per visitor per file. It also takes load off your origin, which can lower your hosting tier and your egress bill — the cost link in why cloud bills spike.

What it fixes, and what it does not

A CDN speeds up static content and absorbs traffic spikes; many also handle SSL and basic caching, complementing the HTTPS explained in what SSL/HTTPS is. It does not make a slow database query or a heavy server-rendered page fast — for that you fix the origin. So a CDN is a multiplier on an already-reasonable site, not a cure for a broken one.

The small-site and tier-1 case

For a small or regional site the case is strong and cheap: several CDNs have generous free tiers, and the win is largest exactly where the origin is far from the readers — a Nigerian or Indian audience served from a US or European origin sees the biggest gain. The one caveat is correctness: caching means you must handle invalidation when you update a file, or visitors see a stale version. Set sensible cache rules, purge on deploy, and a CDN becomes the simplest performance upgrade on this whole shelf.