What a CDN is
MDN defines a CDN as a group of servers spread out over many locations that store duplicate copies of data, so that requests can be answered by the server closest to the user. Your own server is called the origin. The CDN's servers sit in what providers call points of presence. When a visitor in Sydney asks for your logo, a server in or near Sydney answers. Only if it has no fresh copy does it fetch one from your origin, keep it, and pass it on.
In HTTP terms a CDN is a shared cache. RFC 9111 defines a shared cache as one that stores responses for reuse by more than one user, and a private cache as one dedicated to a single user, such as the browser's own. MDN files CDNs under managed caches: caches that the site owner deploys on purpose, controlled by the Cache-Control header and the CDN's own settings. That split is the whole safety model. Anything a shared cache stores can be served to everyone.
Cache hit ratio: what it saves
The share of requests the CDN answers from its cache is the cache hit ratio. web.dev calls a ratio of 90 percent a good goal for most sites. The arithmetic shows why it matters so much: every point near the top cuts the load on your origin sharply.
| Cache hit ratio | Requests reaching the origin (per 1,000,000) | Load cut by a factor of |
|---|---|---|
| 0% | 1,000,000 | 1.0 |
| 50% | 500,000 | 2.0 |
| 75% | 250,000 | 4.0 |
| 90% | 100,000 | 10 |
| 95% | 50,000 | 20 |
| 99% | 10,000 | 100 |
Going from 90 to 99 percent cuts origin requests from 100,000 to 10,000, another tenfold drop. web.dev also notes a trade-off: a CDN with many points of presence can deliver lower latency but may see lower hit ratios, because each location fills its own cache.
The headers that decide what gets cached
A CDN reads the same caching headers as a browser, plus a few aimed only at shared caches:
| Header | Effect |
|---|---|
| Cache-Control: max-age=N | Fresh for N seconds in every cache, browser and CDN alike |
| Cache-Control: s-maxage=N | Overrides max-age for shared caches such as a CDN only |
| Cache-Control: private | A shared cache must not store it; the browser may |
| Cache-Control: no-store | Nobody stores it |
| CDN-Cache-Control: max-age=N | Freshness for CDN caches only (RFC 9213) |
| Age: N | Sent by the cache: seconds since the response was generated or validated |
RFC 9111 says s-maxage overrides max-age for a shared cache, which lets you keep a page short-lived in browsers and longer at the CDN. RFC 9213 goes one step further with CDN-Cache-Control, aimed only at CDN caches. Its own example gives three lifetimes in one response:
Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600A CDN that supports the header keeps the response fresh for 600 seconds, other shared caches for 120, and the browser for 60. If you send no caching headers at all, caches may still guess. RFC 9111 calls this heuristic freshness and gives 10 percent of the time since the file was last modified as a typical setting. MDN recommends sending an explicit Cache-Control on every response instead. The Cache-Control guide covers each directive in detail.
Keeping private pages out
The most serious CDN mistake is caching a page meant for one person. RFC 9111 has two rules against it. A shared cache must not store a response marked private. And it must not reuse a response to a request that carried an Authorization header unless the response explicitly allows shared caching. Cookies get no such protection by default: MDN advises sending Cache-Control: private for personalised content rather than relying on the cookie. Account pages, carts and anything that greets the user by name need private or no-store.
Static files: cache them for a long time
Files whose content never changes are the easiest win. web.dev suggests a long time to live for static content, for example 6 months or 1 year. That only works if a changed file gets a new URL. MDN calls this cache busting: put a version or a hash in the file name, such as bundle.v123.js or bundle.YsAIAAAA.js, and change it on every release. The old URL can stay cached forever because nothing links to it any more, and the new one is fetched fresh.
For HTML, which keeps the same URL, use a short lifetime or revalidation. web.dev notes that even dynamic content can be cached for very short periods, for example 5 seconds, which keeps an origin alive when a page suddenly gets thousands of visits in a minute.
What a CDN does for content it cannot cache
A CDN can still help with pages it must fetch fresh each time. web.dev explains that the visitor's connection ends at a nearby CDN server, which avoids the cost of setting up a new connection across the world, and that the CDN keeps pre-warmed connections to your origin, so data flows at full speed right away. For a site with visitors far from its server, that alone can shorten the wait before the first byte arrives. The Core Web Vitals guide shows where server response time feeds into the page experience metrics.
Does a small site need one?
web.dev's advice leans toward using a CDN for the whole site, but adds that no single approach is universally better and that the right setup depends on the site and its users. A practical way to decide:
- Visitors on several continents, server on one: a CDN helps. Distance is the one thing your server cannot fix.
- Traffic that can spike, from a newsletter, a launch or a link on a big site: a CDN with even short caching protects the origin.
- Large static files such as images, fonts and downloads: a CDN takes them off your server and your bandwidth bill.
- A local business with local visitors on a fast host: good Cache-Control headers may be all you need.
Check what you already have first. Run your home page through the header checker described below: if a cache header is already there, your host may be running a cache in front of your site without you having set one up. The free website hosting list compares free plans if you are choosing a host anyway.
Checking a CDN
Run a page through the HTTP header checker twice. A cached response carries an Age header, which RFC 9111 defines as the cache's estimate of the seconds since the response was generated or validated at the origin. A second request with a higher Age means the cache answered. Most CDNs add their own hit or miss header too, with names that differ by provider. Then compare load times from the website speed test before and after, and watch the hit ratio in the CDN's own analytics. If Cache-Control says private on files that are the same for everyone, that is usually the first thing to fix.
Frequently asked questions
What is a CDN in simple terms?
A content delivery network is a group of servers in many locations that keep copies of your files and answer visitors from a nearby server instead of your own. MDN describes it as servers that store duplicate copies of data so the closest one can answer. Your server, called the origin, only has to answer when the CDN does not have a fresh copy.
Does a small website need a CDN?
Not always. If your visitors are close to your server and traffic is steady, a well-configured server with good Cache-Control headers may be enough. A CDN helps most when visitors are spread across continents, when a page can suddenly get a lot of traffic, or when your host is slow to answer. Check first whether your host already runs one in front of your site.
Does a CDN help with dynamic pages?
Somewhat. web.dev notes that even responses the CDN cannot cache arrive faster, because the visitor connects to a nearby server and the CDN reuses a warm connection to your origin. It also suggests caching dynamic responses for very short times, such as 5 seconds, to protect the origin during traffic spikes.
How do I know if a response came from the CDN cache?
Look at the response headers. A cache that serves a stored response sends an Age header with the number of seconds since the response was generated. Most CDNs add their own hit or miss header as well, and their names differ by provider. An HTTP header checker shows all of them.
Can a CDN show one user's page to another user?
Only if the response was allowed into a shared cache. RFC 9111 says a shared cache must not store a response marked Cache-Control: private, and must not reuse a response to a request with an Authorization header unless a directive explicitly allows it. Mark every personalised page private or no-store.
Sources
- MDN Web Docs: CDN glossary entry (servers in many locations storing duplicate copies, answering from the server closest to the user)
- MDN Web Docs: HTTP caching (shared, proxy and managed caches; CDNs as managed caches controlled with Cache-Control and their own configuration; heuristic caching; Age; cache busting with versioned file names; Vary)
- RFC 9111, HTTP Caching (shared and private cache definitions; s-maxage overrides max-age for shared caches; private forbids storage in a shared cache; the Authorization rule; the Age header; heuristic freshness with a typical 10 percent fraction)
- RFC 9213, Targeted HTTP Cache Control (the CDN-Cache-Control header and the example with max-age=60, s-maxage=120 and CDN-Cache-Control: max-age=600)
- web.dev: Content delivery networks (origin server; points of presence; a cache hit ratio of 90 percent as a good goal; long TTLs such as 6 months or 1 year for static content; 5-second caching of dynamic content; connection reuse for uncached content)