What Is a CDN (Content Delivery Network)? A Developer's Guide

7 min read

A content delivery network (CDN) is a geographically distributed group of servers that cache copies of your website's content and serve each visitor from a location physically close to them. Instead of every request traveling to a single origin server, the CDN answers from a nearby edge node, reducing latency and offloading traffic from your infrastructure.

What a CDN actually is

At its core, a CDN is a network of edge servers (also called points of presence, or PoPs) spread across many cities and regions. Each edge server stores cached copies of static assets such as images, CSS, JavaScript, fonts, and video segments. When a user requests one of these files, the request is routed to the nearest edge server rather than back to the origin — the server where your site is actually hosted.

The reason this matters comes down to physics. Network requests travel as signals through cables, and even at near-light speed, distance adds measurable round-trip time. A visitor in Tokyo fetching files from a server in Virginia pays a latency penalty on every request. A CDN shortens that distance by keeping a copy of the content much closer to the user, so the data has less ground to cover.

How a CDN works

The mechanism is request routing plus caching. When you put a site behind a CDN, you point your domain's DNS at the CDN instead of directly at your origin — usually with a CNAME record. From then on, the CDN sits between visitors and your origin. You can model the records involved with a DNS Record Builder before making changes in production.

The typical flow looks like this:

  1. A browser requests a file. DNS resolves the hostname to the IP of a nearby CDN edge server.

  2. If the edge server already has a fresh copy of the file (a cache hit), it returns it immediately.

  3. If it does not have the file or the copy is stale (a cache miss), the edge server fetches it from the origin, returns it to the user, and stores a copy for the next request.

Whether a file is cached, and for how long, is governed by HTTP response headers. The Cache-Control header (for example Cache-Control: public, max-age=31536000) tells the CDN and the browser how long a response may be reused. The ETag and Last-Modified headers let the CDN revalidate a cached file with the origin and receive a lightweight 304 Not Modified response when nothing has changed, avoiding a full re-download. You can examine what your origin returns with an HTTP Header Inspector, and look up status-code meanings in the HTTP Status Codes reference.

Static vs. dynamic content

CDNs cache static content most effectively — files that are identical for every visitor. Truly dynamic responses (a personalized dashboard, a logged-in cart) are harder to cache because they differ per user. Modern CDNs handle this with techniques such as caching by query string or cookie, caching only the cacheable fragments, or running code at the edge. But the baseline win is always serving static assets fast.

What a CDN does beyond speed

Latency reduction is the headline feature, but a CDN provides several other benefits that often matter just as much.

  • Origin offload. Cache hits never reach your origin server, so the edge network absorbs the bulk of traffic. Your origin handles far fewer requests, which lowers bandwidth costs and reduces load.

  • Resilience under traffic spikes. Because the edge layer serves most requests, a sudden surge — a viral link, a product launch — is spread across many edge servers instead of overwhelming one origin.

  • TLS termination. CDNs typically terminate HTTPS at the edge, handling certificate negotiation close to the user, and most can provision and renew certificates automatically. You can inspect any certificate's details with an SSL Certificate Decoder.

  • Security filtering. Many CDNs include DDoS mitigation and a web application firewall (WAF), filtering malicious traffic before it ever reaches your origin.

When you should (and shouldn't) use one

A CDN is most worthwhile when your audience is geographically spread out, when you serve heavy static assets like images or video, or when traffic is bursty and you need the origin protected. Documentation sites, marketing pages, single-page applications, and media-heavy sites are classic candidates.

It is less essential when your users are concentrated in one region near your origin, when traffic is low and predictable, or when nearly every response is uniquely dynamic and uncacheable. Even then, a CDN can still add value for TLS handling and DDoS protection — but the caching benefit shrinks, so weigh the operational overhead against the gain.

Common pitfalls to avoid

Most CDN problems trace back to caching configuration rather than the CDN itself.

  • Serving stale content. If you set a long max-age and then deploy a change, users may keep getting the old file until the cache expires. The standard fix is cache busting: include a content hash or version in the filename (such as app.9f2c1.js) so a changed file gets a new URL and a fresh cache entry.

  • Caching things that shouldn't be cached. If an edge server caches a response containing user-specific or authenticated data, it can be served to the wrong person. Mark such responses Cache-Control: private, no-store and be deliberate about which cookies and headers affect caching.

  • Forgetting to purge. After deploying, you often need to invalidate or purge the cache so the edge fetches the new version. Relying solely on expiry can leave stale content live for hours.

  • Cross-origin issues. Serving assets from a CDN hostname different from your page can trigger CORS restrictions for fonts, scripts, and fetch requests. Configure the right Access-Control-Allow-Origin headers; a CORS Headers Builder helps you assemble them correctly.

When you load third-party scripts or styles from a CDN, add Subresource Integrity so the browser verifies the file matches a known hash and rejects tampered content. Generate the attribute with an SRI Hash Generator. It is also worth minifying assets before they reach the edge — smaller files transfer faster — using a JavaScript Minifier or its CSS equivalent.

CDN vs. related concepts

A CDN is sometimes confused with neighboring ideas. A reverse proxy sits in front of an origin to route and cache requests, and a CDN is essentially a globally distributed reverse-proxy network. Edge computing goes a step further, running custom code at edge locations rather than only caching static files. DNS-based load balancing distributes traffic across servers but does not cache content the way a CDN does. The distinction worth remembering: a CDN's defining job is to cache and serve content from locations close to your users, reducing both distance and origin load.

Frequently Asked Questions

No. A CDN caches and serves copies of your content, but it still needs an origin server where the canonical version lives. The origin handles cache misses, dynamic requests, and any content the CDN cannot cache.

It helps most for sites with geographically spread visitors or heavy static assets like images, video, and scripts. A small, low-traffic site whose users are all near its origin will see a smaller benefit, though TLS handling and DDoS protection can still be worthwhile.

It follows the HTTP caching headers your origin sends, primarily Cache-Control with a max-age value, plus ETag and Last-Modified for revalidation. You can inspect those headers with the HTTP Header Inspector tool.

Cache busting changes a file's URL whenever its contents change, usually by embedding a content hash in the filename. Without it, visitors may keep receiving an old cached version after you deploy an update until the cache naturally expires.

A CDN is essentially a globally distributed network of reverse-proxy caches. A single reverse proxy sits in front of one origin in one place, while a CDN replicates that caching role across many edge locations worldwide to serve users from nearby.

Related Guides