What Is a CDN (Content Delivery Network)? How It Works

What is a CDN (Content Delivery Network)?

A content delivery network (CDN) is a group of servers spread across many locations that store copies of your content and answer each request from the location closest to the visitor. It shortens the distance data travels, takes load off your own server and keeps popular content available when traffic spikes.

Your own server stays the source of truth and is called the origin. The CDN servers in front of it are called edge servers. MDN describes the idea the same way: duplicate copies of data, served by the servers nearest to each user.

How a CDN works

1. The browser requests a URL on your domain, and DNS points it to a CDN edge server near the visitor.
2. The edge checks its cache. On a hit it answers immediately. On a miss it fetches the file from the origin (or from a mid-tier cache), stores a copy and then answers.
3. Later visitors in that area get the stored copy until it expires (its TTL) or you purge it.

The share of requests answered from cache is the cache hit ratio, the number that tells you whether the CDN is doing its job. The same idea applies one level down, to API caching.

What to cache and what to keep out

The Cache-Control response header tells the CDN what it may store and for how long.

Be careful with the names: no-cache does not mean "do not store", it means "check with the origin before reusing". no-store is the one that stops storing. The MDN Cache-Control reference lists every directive.

Why use a CDN

• Lower latency. Distance affects latency, and a nearby edge server is closer than your origin for most of the world. This is also where time to first byte improves first.
• Less load on the origin. Every request answered at the edge is one your own servers never see, so you can run smaller infrastructure for the same traffic.
• Traffic spikes. Cached content keeps being served while your origin would otherwise queue up.
• Resilience. If one edge location has trouble, requests can be routed to another. Cached copies can keep answering while the origin is slow.
• Protection and extras. Many providers terminate TLS, compress responses and filter abusive traffic at the edge. That helps against floods (see how to stop DDoS attacks) but does not replace rate limits on your own origin.

Common CDN mistakes

• Stale files after a deploy. Give static assets hashed filenames so a new release means a new URL, and purge only the few URLs that cannot change name, such as HTML. Our post on cache invalidation and performance testing goes deeper.
• Caching personalized responses. Forgetting private on a user-specific response can let a shared cache hand it to another user. MDN warns about exactly this.
• A cache key that is too specific. If cookies or random query parameters are part of the key, the CDN stores one copy per variant and the hit ratio collapses. Remove whatever does not change the response.
• Cache stampede. When a popular object expires, many edges ask the origin at once. stale-while-revalidate, or an origin shield tier, absorbs that.
• Assuming a CDN is always faster. MDN notes that a third-party host adds its own DNS lookup and connection. For an audience that sits next to your origin the gain can be small, so measure it.
• Never testing a cache miss. After a purge or a deploy the origin has to carry the full load for a while.

CDN vs edge computing

A CDN stores and serves content. Edge computing runs your code at those same locations, for example to rewrite a request or personalize a response close to the user. Many providers offer both, but only the first one is a CDN in the classic sense.

How to test and monitor a CDN

• Read the response headers. The Age header shows how long the object has sat in a proxy cache; a value of 0 usually means it came from the origin. Most providers also add their own cache-status header. The free curl Online tool sends the same request from six AWS regions and shows status, headers and timing, so you can compare edges.
• Watch speed by region. Page speed monitoring runs scheduled Lighthouse audits from 25 cloud regions, which shows whether the CDN helps everywhere or only near your origin. Track it together with Core Web Vitals.
• Test beyond the cache. A load test against a cached URL mostly measures the CDN. Also test with cache-busting requests to see what your origin does on a cold cache. Our post on edge locations in cloud testing explains why test location matters.

FAQ: CDN

Do I need a CDN for a small site?

If nearly all your visitors are in one region close to your server, the gain is small. If visitors are spread around the world, or you want a buffer for traffic spikes, a CDN is worth it. Many providers offer a free or low-cost starting tier.

Can a CDN cache API responses?

Yes, with care. Read-only GET responses that are the same for every user cache well. Anything personal, such as GET /me, must be marked private or no-store. Use Cache-Control and Vary headers deliberately.

How do I clear cached content after a deploy?

Use versioned or hashed filenames for static assets, so a new release gets a new URL and nothing needs clearing. For URLs that keep their name, such as HTML pages, call your provider purge API after the deploy.

How do I know a response came from the CDN cache?

Look at the response headers. A non-zero Age header means the object was served from a proxy cache, and most CDNs add their own header that says hit or miss. Repeat the request and compare.

Does a CDN protect against DDoS attacks?

It helps, because floods are absorbed at the edge before they reach your origin. It does not replace rate limiting, a web application firewall and a plan for application-layer floods on dynamic endpoints.

Does a CDN affect SEO?

Indirectly. Faster loading can improve Core Web Vitals, which Google recommends getting right for Search. A badly configured cache can also serve outdated titles and meta tags or block crawlers, so check what the CDN returns to Googlebot.