--- title: "What Is a CDN? What It Does Under Load | Evaluat" description: "What a CDN is, how it takes cacheable traffic off your server under load, what still reaches your origin on sale day, and how to load test with a CDN in front." url: "https://www.evaluat.com/blog/what-is-a-cdn" last_modified: "2026-10-19" --- [Blog](https://www.evaluat.com/blog) [Guides](https://www.evaluat.com/blog/category/guides) # What a CDN does (and does not) do for your site under load A content delivery network (CDN) is a network of servers that keeps copies of your files close to your visitors and answers for your own server whenever it can. Under load it can absorb most requests for pages and files that are the same for everyone. Baskets, checkouts and every order still reach your server. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 19 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 14How a web page loads ![A CDN receives 2,000 requests a second. Bars show how many reach the origin server at each cache hit ratio: 400 a second at 80 percent, 200 at 90 percent, 100 at 95 percent and 20 at 99 percent. Dropping from a 95 to a 90 percent hit ratio doubles the origin's traffic, and baskets, checkouts and orders are always among the requests that get through.](https://www.evaluat.com/blog/what-is-a-cdn-cover.svg) Summary A content delivery network, or CDN, is a network of servers in many locations that sits between your visitors and your own server, which is called the origin. When a file or page is the same for everyone, the CDN keeps a copy and answers from a server near the visitor, without asking the origin at all. That is called a cache hit. Under load this matters a great deal. If the CDN answers ninety five percent of requests, only one in twenty reaches your server, and raising that to ninety nine percent cuts the origin's share by another four fifths. A CDN also bundles a rush of identical requests into one, and can keep serving a slightly old copy while your server struggles. What it cannot do is the shop's personal work. Baskets, checkouts, account pages, search results and every order a customer places still go to your server, and on sale day those are the busiest pages of all. Purging the whole cache, or a campaign link that adds a new parameter to every address, can also send a flood of requests back to the origin. So test both ways. Test through the CDN to see what shoppers get, and test the pages it cannot cache to see what your server can really carry. Listen to this article · 1:20 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/what-is-a-cdn.mp3) Key takeaways - A CDN answers cacheable requests from a server near the visitor, so they never reach your origin. - Hit ratio is the share of requests the CDN answers itself; moving it from 90% to 95% halves the requests your origin sees. - Baskets, checkouts, account pages and every POST request, such as placing an order, still go to your origin. - A purge of the whole cache, or a tracking parameter that splits the cache, can send a flood back to the origin. - Load test through the CDN to see what shoppers get, and test the uncached journeys to find what your server can carry. ## What is a CDN? A content delivery network (CDN) is a network of servers spread across many locations that sits between your visitors and your own server. It keeps copies of files and pages that are the same for everyone and answers visitors from a server near them. Your server, called the origin, only answers when the CDN has no usable copy. MDN’s glossary sums up the promise: [CDNs make for fast service less affected by high traffic](https://developer.mozilla.org/en-US/docs/Glossary/CDN). Both halves of that sentence matter in this guide. Fast service comes from distance, which [part 10](https://www.evaluat.com/blog/latency-vs-bandwidth) covered. Being less affected by high traffic comes from caching, and that is the half this article is about. A few terms are worth fixing now. The servers near visitors are called edge servers. A request the CDN can answer from its own copy is a cache hit; one it has to pass to your server is a cache miss. The cache key is what the CDN uses to decide whether two requests are for the same thing, usually the full address including its query string. A chain of local depots is a fair picture. Everyday stock sits in a depot near every customer, so most orders never trouble the factory. A made-to-order item still has to come from the factory, however many depots you open. Under load, the question is how much of your traffic is everyday stock. ## How does a CDN work? When a visitor requests a page, the CDN routes them to a nearby edge server. That server checks its cache for a copy matching the request’s cache key. On a hit it answers straight away. On a miss it fetches the response from your origin, stores it if the response’s caching headers allow, and passes it on. Your server decides what may be cached. A `Cache-Control` header on each response tells the CDN whether to store it and for how long, and many CDNs add their own defaults on top. Files such as images, scripts and stylesheets are the usual candidates. HTML is less often cached: the 2025 Web Almanac found that [HTML content has the lowest CDN usage at 35%](https://almanac.httparchive.org/en/2025/cdn) of any content type it measured. Even a miss gains something. The visitor’s connection is opened and secured at the nearby edge, not at your distant origin, which is why the connection phases from [part 8](https://www.evaluat.com/blog/how-a-web-page-loads) shrink behind a CDN. On the far side, the CDN keeps its own connections to your origin open. Amazon CloudFront’s documentation says that [maintaining a persistent connection saves the time required to re-establish the TCP connection and perform another TLS handshake for subsequent requests](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html). ## What does a CDN do for your site under load? Under load a CDN does four useful things. It answers cacheable requests without asking your origin, it merges a rush of identical misses into one, it can add a second layer of cache in front of your origin, and it can keep serving a slightly stale copy while your origin struggles. Each one depends on how you configure it. ### It answers requests your origin never sees The measure here is the cache hit ratio. Fastly defines it as [the percentage of requests a CDN can serve from its cache](https://www.fastly.com/blog/origin-offload-a-measure-of-cdn-efficiency-for-reducing-egress-cost), rather than fetching from the origin. The arithmetic is less intuitive than it looks. In the same 2024 article Fastly’s engineers point out that [if your CHR increases from 90% to 95%, it’s not merely a 5% improvement; it actually halves your origin load](https://www.fastly.com/blog/origin-offload-a-measure-of-cdn-efficiency-for-reducing-egress-cost). At the top end the effect is dramatic. Troy Hunt, who runs Have I Been Pwned, reported in 2023 that after tuning his Cloudflare setup [it was now only 5k requests per million hitting the origin](https://www.troyhunt.com/to-infinity-and-beyond-with-cloudflare-cache-reserve/). That is a hit ratio of 99.5%: his servers saw one request in two hundred. ### It merges a rush of identical misses When a popular item is not in the cache, many visitors can ask for it in the same instant. CloudFront handles this with request collapsing: if more requests for the same object arrive before the first response returns, [CloudFront pauses before forwarding the additional requests to the origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) and answers them all from the one response. Cloudflare and Fastly do something similar. There is a limit. CloudFront [only collapses requests that share a cache key](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html), so requests that differ by query string, cookie or header each go to your origin. ### It can put a second cache in front of your origin Most large CDNs offer a middle layer, called an origin shield or tiered cache, that sits between the edge servers and your origin, so misses at many edges can become a single request to your origin. AWS says that with Origin Shield, requests for the same uncached object are consolidated, [resulting in as few as one request going to your origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html), which can preserve the origin’s availability during peak loads. The same page is candid that it [may not be a good fit](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html) for dynamic content that is proxied to the origin. ### It can keep serving while your origin struggles Two `Cache-Control` extensions from [RFC 5861](https://www.rfc-editor.org/rfc/rfc5861) let a cache bend the rules. `stale-while-revalidate` lets it serve an expired copy while it fetches a fresh one in the background. `stale-if-error` means that when the origin returns an error, a cached stale response may be used to satisfy the request. On a bad afternoon, a product page that is ten minutes old beats an error page. Your origin has to send these directives, and your CDN has to support them. ## What still reaches your origin under load? Everything that is personal to one visitor or that changes something. Baskets, checkouts, account pages, many search results and every request that adds to a basket or places an order go to your origin, along with every cache miss. On sale day those are the busiest requests on the site, so they set your real capacity. CloudFront’s rule is typical: it [always caches responses to GET and HEAD requests](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html), can be set to cache OPTIONS, and does not cache responses to requests that use other methods. Adding to a basket and placing an order are POST requests, so no CDN setting can answer them for you. Cached pages can still call home. On Adobe Commerce (Magento), the personal parts of a cached page, such as the mini-basket, are loaded separately: JavaScript [sends an AJAX request to the application server to get the current private content](https://developer.adobe.com/commerce/php/development/cache/page/private-content). A product page served entirely from the CDN can still put one request per visitor on your origin. | Request | Usually answered by the CDN? | Why | | ----------------------------------------- | ----------------------------------- | -------------------------------------------------------------- | | Images, scripts, stylesheets, fonts | Yes | The same for everyone, with long cache lifetimes | | Product and category pages | Only if your setup allows it | Some CDNs, Cloudflare among them, do not cache HTML by default | | Personal parts of a cached page | No | Different for every visitor | | Basket, checkout and account pages | No | Personal, and usually set cookies | | Add to basket, place order | No | POST requests that change data | | Search results | Partly | A long tail of unique addresses | | Addresses with unique tracking parameters | No, unless the parameter is ignored | Each variant is a new cache key | A CDN also obeys your origin. In 2020 Request Metrics traced a blog outage during an 800% traffic surge to a `cache-control` header that marked the blog’s pages as uncacheable. As its chief executive, Todd Gardner, put it, [Cloudflare is honoring that instruction and passing every request through to the server](https://requestmetrics.com/blog/performance/how-hackernews-crushed-davidwalshblog/). The CDN was there. It was told not to help. ## How much load does a CDN take off your origin? The share of requests it answers itself, and that share moves more than people expect. A small drop in hit ratio can double what reaches your origin, and the requests that are left are the expensive ones. Work out both numbers, requests reaching the origin and the work each one costs, before trusting a CDN on sale day. Take an example store whose CDN receives 2,000 requests a second at its peak, counting pages, files and background calls together. | Cache hit ratio | Requests reaching the origin each second | | --------------- | ---------------------------------------- | | 80% | 400 | | 90% | 200 | | 95% | 100 | | 99% | 20 | Now suppose a campaign email adds a unique tracking parameter to every link, and the CDN treats each one as a new address. The hit ratio slips from 95% to 90%. The CDN dashboard still looks healthy, yet the origin’s request rate has doubled from 100 to 200 a second. The count is only half the story. Fastly warns that [if your objects vary greatly in size, CHR won’t accurately represent the origin load](https://www.fastly.com/blog/origin-offload-a-measure-of-cdn-efficiency-for-reducing-egress-cost), and the same is true of the work behind each request. A missed image costs your server a file read. A checkout page costs database queries, stock checks and calls to a payment provider. On sale day more shoppers reach the basket, so the uncacheable share grows just as traffic peaks. ## What happens when the CDN cache is empty? Every request becomes a miss, and your origin takes the full load until the cache refills. That happens after a full purge, after a release that changes the addresses of files, and when a new parameter splits the cache. At peak, any of these can multiply your origin’s traffic within minutes. Cloudflare’s documentation is blunt about purging everything: [every subsequent request must be served from your origin until the cache is repopulated](https://developers.cloudflare.com/cache/how-to/purge-cache/purge-everything/), and on high-traffic sites that can cause a large spike in origin requests. Purge the pages that changed, not the whole cache, and do not schedule a full purge for the morning of a sale. Akamai’s Pavel Despot, writing in February 2026 about peak traffic, noted that [caching is often the first line of defense](https://www.akamai.com/blog/cloud/observing-anatomy-peak-traffic). A first line of defence that can be switched off by one button deserves a rule about when that button is pressed. This is one reason the [code freeze in part 11](https://www.evaluat.com/blog/black-friday-code-freeze) should cover CDN configuration as well as code. ## Should you load test through your CDN or around it? Do both, because they answer different questions. A test through the CDN shows what shoppers will experience, with your real cache rules, edge locations and bot protection in place. A test of the uncached journeys, or with the cache bypassed, shows what your origin can carry when the CDN cannot help. Testing through the CDN has two traps. A test that loops over a handful of addresses fills the cache in seconds and flatters the hit ratio, while real shoppers spread across thousands of products, search terms and tracking links. And CDNs have their own rules. AWS says [traditional load testing methods don’t work well with CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/load-testing.html), recommends spreading test clients across locations and DNS answers, and does not allow load testing on origins that have Origin Shield enabled. Other providers have their own terms, and bot protection can challenge test traffic, so agree the plan with whoever runs your CDN before the test. Testing around the CDN gives you the floor. If your origin cannot serve your forecast basket and checkout traffic on its own, no cache setting will save the day, because that traffic was never going to be cached. ## Common mistakes with CDNs and load Most CDN surprises come from assuming the cache covers more than it does. - **Load testing the homepage and calling it capacity.** It is the most cached page on the site. Test the basket and checkout journeys, which [part 12](https://www.evaluat.com/blog/time-to-first-byte) showed are the pages that expose your origin. - **Assuming HTML is cached.** Check the response headers on your product pages. Some CDNs pass HTML through unless told otherwise. - **Letting parameters and cookies split the cache.** Configure the cache key to ignore tracking parameters that do not change the page. - **Purging everything at peak.** Purge only what changed, and keep full purges out of sale days. - **Reading only the hit ratio.** Watch requests reaching the origin and the response times of the pages behind them. ## How Evaluat shows what your CDN does under load Every virtual user is a real browser, so an Evaluat test goes through your CDN the way a shopper does: the page, its files, the background calls for personal content, the basket and the checkout. Each session’s network log shows the cache state of every request that reports one: served from the browser’s own cache, or the verdict your CDN or proxy gave in headers such as `cf-cache-status` and `x-cache` (hit, miss, bypass and so on). That lets you see the split this article describes while load is running. You can check which requests your CDN answered and which went to your origin, and watch time to first byte on the uncached pages as virtual users ramp up. Then open a slow session and see which request it was waiting for. The boundary is worth stating. Evaluat runs from the region closest to your customers, not from every edge location your CDN has, and it shows what its browsers saw under the test conditions you chose. Your CDN’s own analytics remain the place to read hit ratios across all of your real traffic. A CDN is often the cheapest capacity a site can buy, and it covers less of a shop than it seems to. Know which of your requests it answers, test the ones it cannot, and keep the purge button away from sale day. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to see your checkout measured through your CDN under load. [Previous · Part 13What is volume testing?](https://www.evaluat.com/blog/what-is-volume-testing) [Next · Part 15Why websites crash under high traffic](https://www.evaluat.com/blog/why-websites-crash-under-high-traffic) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What is a CDN in simple terms? A CDN is a network of servers in many places that keeps copies of a website's files and answers visitors from the server nearest to them. Your own server, the origin, only has to answer when the CDN does not have a usable copy. The result is shorter trips for visitors and fewer requests for your server. ### Does a CDN help with high traffic? Yes, for content that is the same for every visitor. Images, scripts, stylesheets and cached pages are answered at the edge, so a traffic spike on those barely reaches your server. Requests that are personal or change something, such as adding to a basket or placing an order, still go to your server, so a CDN alone does not make a checkout survive a sale. ### Does a CDN cache dynamic content? Not by default. Most CDNs cache responses to GET and HEAD requests only when the response allows it, and some, Cloudflare among them, do not cache HTML unless you configure them to. Pages that differ per visitor, such as a basket or an account page, should not be cached and are passed through to your server. ### Does a CDN reduce server load? Yes, by the share of requests it answers itself, known as the cache hit ratio. At a 95% hit ratio, one request in twenty reaches your server. The requests that remain are usually the expensive ones, such as checkout and search, so server load falls by less than the request count suggests. ### What is a good CDN cache hit ratio? There is no universal target, because it depends on how much of a site is the same for everyone. Static files often reach the high nineties, while sites with many personal pages sit lower. Watch the number of requests reaching your origin as well as the ratio, since a small drop in the ratio can double the origin's work. ### Should I load test through my CDN or bypass it? Do both, because they answer different questions. A test through the CDN shows what shoppers experience, including your real cache rules, while a test of the uncached journeys, or with the cache bypassed, shows what your origin can carry after a purge or a CDN problem. Check your CDN provider's rules on load testing first. ### What is the difference between a CDN and web hosting? Web hosting runs your site: it stores the application, builds the pages and talks to the database. A CDN sits in front of the host, keeps copies of what can be shared and answers visitors from nearby. A CDN cannot run your site on its own; it always needs an origin behind it. ### Do I need a CDN for a small website? Not always, but most sites benefit, and many CDNs have free plans. A CDN shortens connection times for visitors far from your server and takes static files off it. For a small shop the bigger risk on a busy day is usually the uncached pages, so a CDN is a sensible first step, not a capacity plan. Related reading ## More from the blog [![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg)](https://www.evaluat.com/blog/time-to-first-byte) ### [Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte) [Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue.](https://www.evaluat.com/blog/time-to-first-byte) [Ahmad Farzan · 8 October 2026](https://www.evaluat.com/blog/time-to-first-byte) [![Two comparisons of where a page load's wait goes. Upgrading broadband from 100 Mbps to 1 Gbps cuts the transfer of a 2.6 MB page from 0.21 seconds to 0.02 seconds, saving about 0.19 seconds. Shortening each round trip from 140 milliseconds to 30 milliseconds cuts a page that needs ten round trips in a row from 1.4 seconds of waiting to 0.3 seconds, saving 1.1 seconds.](https://www.evaluat.com/blog/latency-vs-bandwidth-cover.svg)](https://www.evaluat.com/blog/latency-vs-bandwidth) ### [Latency, bandwidth and round trips, explained](https://www.evaluat.com/blog/latency-vs-bandwidth) [Faster broadband does not make a slow website fast. Bandwidth is how much data a connection carries each second; latency is how long one trip takes. A web page needs dozens of small trips, so once a connection passes about 20 Mbps, the number and length of those trips decide the wait, not the size of the pipe.](https://www.evaluat.com/blog/latency-vs-bandwidth) [Ahmad Farzan · 3 October 2026](https://www.evaluat.com/blog/latency-vs-bandwidth) [![Five cache layers between a shopper and the database, drawn left to right: browser cache, CDN, full-page cache, object cache and database memory. A request for a product page is answered by the full-page cache and stops there. A basket request uses the browser cache for files only, skips the CDN page cache and the full-page cache, and goes on to the object cache and the database.](https://www.evaluat.com/blog/caching-explained-cover.svg)](https://www.evaluat.com/blog/caching-explained) ### [Caching explained: browser, CDN, full-page and object caches](https://www.evaluat.com/blog/caching-explained) [Caching means keeping a copy of something expensive to produce so the next request can be answered faster. A busy online shop has five layers of it between a shopper and the database. Basket, checkout and account requests skip the two layers that store whole pages, which is why they slow first under load.](https://www.evaluat.com/blog/caching-explained) [Ahmad Farzan · 22 October 2026](https://www.evaluat.com/blog/caching-explained) See it on your site Test in real browsers.\ Debug in real sessions. ## Start with one real-browser page load. Pulse loads a public URL once, returns LCP and CLS plus FCP and TTFB, grades the page, and keeps a video on a shareable link. [Run a free speed test](https://www.evaluat.com/tools/website-speed-test) [Book a demo](https://www.evaluat.com/demo?intent=performance)