Programming · web · performance

What is a CDN?

A CDN (content delivery network) is a group of servers spread across many locations that keep copies of your static content - images, CSS, JavaScript, fonts, videos - and serve each visitor from a server that is geographically close to them. The goal is simple: shorten the distance a request has to travel, so pages load faster and your main server does less work. If your site is hosted in one city, a visitor on the other side of the planet no longer has to reach across the world for every file.

The problem it solves

When your site lives on a single server, every request - from every country - has to reach that one machine and come back. Distance costs time: the further away the visitor, the more latency creeps in, and the busier your server gets as traffic grows. A CDN answers both problems by putting copies of your files closer to people and by taking most of the request load off your origin.

Edge servers and points of presence

The servers a CDN uses to cache and serve content are often called edge servers, sitting at the "edge" of the network, near users, rather than at your central origin. Groups of these are placed in data centres worldwide, sometimes called points of presence (PoPs). When someone requests a file, the CDN routes them to a nearby edge server instead of your origin. Because that server is close, the round trip is shorter and delivery is quicker.

Cache hit, cache miss, and the origin

The core mechanic of a CDN is the cache. The first time an edge server is asked for a file it does not have, that is a cache miss: the edge fetches the file from your origin server, sends it to the visitor, and stores a copy. The next visitor to that same edge gets a cache hit - the file is already there and served immediately, without touching the origin at all.

request -> nearest edge server
  cache HIT  -> serve the stored copy (fast, origin untouched)
  cache MISS -> fetch from origin, serve, then store for next time

This is why a CDN both speeds up delivery and offloads the origin: once content is cached at the edge, most requests are answered without ever reaching your server. Under a traffic spike, the edge network absorbs the bulk of the load.

TTL and invalidation: keeping the cache fresh

A cached copy cannot live forever, or visitors would keep seeing an old version after you update a file. Two mechanisms handle this:

• TTL (time to live): each cached item is given a lifetime, usually driven by HTTP caching headers such as Cache-Control. When the TTL expires, the edge treats the item as stale and re-checks the origin before serving it again.
• Invalidation (purge): when you deploy a change and cannot wait for the TTL, you tell the CDN to drop specific cached files so the next request fetches the fresh version from the origin. A common trick that avoids purging at all is cache busting - changing the file name or adding a version query, for example style.abc123.css, so a new URL is fetched fresh.

Static content vs dynamic content

CDNs shine with static content: files that are the same for everyone and change rarely, like images, stylesheets, scripts and downloads. These cache cleanly and can be served from the edge for a long time. Dynamic content - a personalised dashboard, or a response that depends on who is logged in - is harder to cache, because the answer differs per request. Modern CDNs still help here with features like connection reuse and running small bits of logic at the edge, but the classic, biggest win is caching static assets close to users.

What else a CDN commonly does

Beyond caching, most CDNs bundle useful extras. They typically terminate TLS (HTTPS) at the edge and apply compression so files travel smaller and encrypted. Many also add protection against traffic floods and absorb load that would otherwise hit your origin. Real, widely used CDNs include Cloudflare, Fastly and Akamai; for open-source libraries, public CDNs such as jsDelivr serve packages straight from a global edge network.

Where a CDN fits with your host

A CDN does not replace your hosting - it sits in front of it. Your server or VPS remains the origin that holds the real files and runs your application; the CDN caches and delivers copies of the cacheable parts. It also pairs naturally with a reverse proxy in front of your app: the proxy routes and terminates TLS at your origin, while the CDN handles the global edge layer. You still need a solid origin host underneath it all.

FAQ

Does a CDN replace my web host? No. Your host is the origin that stores the real files and runs your app. A CDN caches and serves copies of the static, cacheable parts from servers near your visitors. You need both: a reliable origin plus the edge layer in front of it.

What is the difference between a cache hit and a cache miss? A hit means the edge server already has the requested file cached and serves it immediately. A miss means it does not, so it fetches the file from your origin, serves it, and stores a copy so the next request is a hit.

What is TTL? Time to live: how long a cached item is considered fresh, usually set by HTTP caching headers. When the TTL expires, the edge re-checks the origin before serving the item again, so updates eventually reach everyone.

Can a CDN cache dynamic content? Partly. Content that differs per user is hard to cache directly, but CDNs still speed it up with connection reuse, compression and edge logic. The biggest, simplest win remains caching static assets like images, CSS and JavaScript close to users.

Related guides: what a reverse proxy is, what a load balancer is, what a VPS is.