What is a CDN and do you need one?

The problem a CDN solves

A browser cannot show your page until data has crossed the distance between your server and the visitor. Every request makes a round trip, and distance adds delay to each one. MDN puts it plainly: geographic distance affects latency proportionally. The first request is the worst. Before the first bytes can flow, the browser has to look up the address, open a connection and secure it, and each step is another trip. Later requests reuse the connection and cost less.

You cannot make data travel faster, so the fix is to shorten the distance. If your server is in one city and a visitor is on another continent, every file takes the long way. A CDN puts copies of the files on servers near the visitor, so most requests take a short trip.

How a CDN works

1. Your address points at the CDN. Setup usually means signing up and changing a DNS record so that your web address leads to the CDN. From then on, visitors connect to a CDN server instead of yours.
2. The visitor reaches a nearby CDN server. CDN companies run many of these servers in cities around the world. They are often called edge servers.
3. The edge server checks for a fresh copy. If it has one, it answers at once. This is a cache hit.
4. If it has none, it asks your server. Your server is the origin. This is a cache miss. The edge server passes your answer to the visitor and, if your headers allow it, keeps a copy.
5. The next visitor nearby gets a hit. The copy stays until its lifetime ends, until the CDN needs the space, or until you clear it.

The most common way to fill the copies is the one above, called origin pull: the CDN fetches a file the first time someone asks for it. Clearing a file before its lifetime ends is called purging, and CDNs usually offer it through an API. Which files the CDN keeps, and for how long, is decided by the cache headers your server sends. See HTTP caching headers.

What a CDN speeds up, and what it cannot

The third row surprises people. web.dev explains that even content a CDN cannot keep is usually faster through one. The visitor opens a connection to a server close by, and the rest of the trip runs over the CDN's own network, which often keeps connections to your server open already.

Many CDNs add more than copies:

• Modern protocols (see HTTP/2 and HTTP/3). In the 2025 Web Almanac's measurements, roughly 29% of mobile page requests answered by a CDN used HTTP/3, against effectively none of those answered by the sites' own servers. Almost all of them, 99%, used TLS 1.3, which needs one round trip instead of two to set up a secure connection.
• Faster address lookups. In HTTP Archive's lab tests, the median DNS lookup for CDN-hosted names took 176 milliseconds on mobile against 217 for sites' own names, and 52 against 129 on desktop. A lab result is a hint, not a promise.
• Compression. Many CDNs offer Brotli, and some Zstandard. See text compression.
• Image changes on the fly. More on that below.
• Relief in traffic spikes. Most requests never reach your server, so a spike lands on the CDN instead of on you.

Do you need one?

Use this table as a first answer.

Cost is less of a barrier than it was. The 2025 Web Almanac found CDN use on 71% of the top 1,000 sites and on 35% of the top 10 million, and it credits free and low-cost plans, and hosts that bundle a CDN, for the growth among smaller sites. Before you buy one, ask your host whether it already runs one in front of your site.

A CDN is not a replacement for a good server. On a hit it hides a slow server. On a miss, which is every first request and every request for a page that cannot be kept, your server is still the one that has to answer. Work on the first byte as well.

Three ways to start

1. Static files only. Put your images, scripts, styles and fonts on a CDN, either through a separate address such as static.example.com or through your platform's setting. This is the lowest-risk step.
2. The whole site. Point your main address at the CDN. Static files are usually kept without further settings. Whether pages are kept depends on the CDN and on your headers, and the CDN still gives you the shorter connection for the pages it cannot keep. web.dev's advice is to deliver as much of the site as possible through the CDN.
3. Public pages cached too. Let the CDN keep your HTML, and clear it when you publish. This is where most of the TTFB gain is, and where most of the mistakes happen. The next section covers the rules.

Settings that decide whether it works

A CDN with the wrong settings is a slower, more expensive copy of your server. These are the settings that matter.

• Cache headers. At a minimum, a file needs Cache-Control: max-age, Cache-Control: s-maxage or Expires to be kept. Versioned static files can be kept for six months to a year. Even a page that changes often can be kept for a few seconds, which web.dev points out can cut the load on your server during busy periods with little effect on freshness.
• Private pages stay out. A response marked Cache-Control: private or no-store is not for the CDN. Check this on anything that depends on a login, a cart or a cookie. This is the mistake with the highest cost: a cached personal page can be shown to a stranger.
• The cache key. The CDN identifies a file by its address. By default it treats /blog and /blog?ref=abc as two files, and ?a=1&b=2 and ?b=2&a=1 as two files. A tracking parameter on every link can make every request a miss. Set the CDN to ignore parameters that do not change the page, and to sort the rest.
• Cookies. web.dev notes that responses carrying Set-Cookie are typically not kept. A plugin that sets a cookie on every page can stop all of them from being kept.
• `Vary`. web.dev warns that not every CDN supports Vary well, and that a Vary it does not support can stop a page from being kept. Test it.
• The hit ratio. The share of requests answered from copies is the cache hit ratio. web.dev suggests 90% as a good goal for most sites. Your CDN's dashboard shows yours. If it is low, the cause is nearly always one of the settings above.
• Clearing. Decide how a change reaches visitors. Either use short lifetimes, or keep pages for long and clear them on publish. web.dev calls the second approach hold-till-told caching. Tags let you clear every page that shares a part, such as a footer, in one step.

Image CDNs

An image CDN is a CDN that also changes images for you. The address of the image carries the size, format and quality you want, and the service creates and keeps each version. Some can choose the best format for each browser automatically. web.dev says that switching to an image CDN can save 40% to 80% of image bytes. The workflow is covered in image optimization and the formats in WebP and AVIF.

Library CDNs are a different thing

Some sites load jQuery, Bootstrap or fonts from a public CDN address, hoping visitors already have the file from another site. That no longer works. Browsers now separate their caches by the site being visited, so a file fetched for one site is not reused for another. MDN lists the HTTP cache, the image, script, stylesheet and font caches among those that are partitioned. The visitor pays for an extra connection and gets no sharing. MDN's glossary also notes that such a CDN adds a dependency on another company and another way to be attacked. Serving the files from your own address, or from your own CDN, avoids the extra connection.

Choosing a CDN

Compare these points rather than brand names:

• Where the servers are. A network with many locations gives shorter trips but splits your traffic across more caches, which can lower the hit ratio. web.dev describes this trade-off and the tiered approach many CDNs use to ease it. Test from the regions your visitors are in.
• Speed in practice. Performance varies by place, by time of day and over time. Measure it yourself.
• Features you will use. Brotli, HTTP/3, clearing by address and by tag, image changes, reports on the hit ratio.
• Price, support and how easy it is to set up. Many hosts include a CDN, which may be enough.
• Dependence. The CDN becomes part of your site. If it fails, your site may fail with it, so choose one with a clear record and a way to switch it off.

Check that it works

1. Look at the headers. Many CDNs add a header that says whether an answer was a hit or a miss. The name differs by company, so check its documentation. An Age header above zero also shows that a shared cache held the copy.
2. Request twice. The first request to a file may be a miss. The second should be a hit.
3. Test from far away. Run a speed test from a location near your visitors, not only from your own city.
4. Watch the real numbers. After the change, follow the first-byte time in real-user data. Lab data and field data explains why that is the number to trust.
5. Look at the dashboard. The hit ratio should climb in the first days and settle.

Check your own page

Run the free audit and look at the server response time and the cache lifetimes of your files. A long wait for a page that is the same for everyone, or a list of files with short lifetimes, are the two signs that a CDN, or better settings on the one you have, will help. If the audit shows a good first response already, spend your time on the biggest items in the report instead.

Sources

• Content delivery networks (CDNs) on web.dev: how CDNs work, caching, choosing one, cache hit ratio and performance features.
• Optimize Time to First Byte on web.dev: CDNs and short cache times for busy sites.
• CDN in the MDN glossary and State partitioning on MDN: library CDNs and partitioned caches.
• Understanding latency on MDN: what makes the first request slow.
• CDN chapter, Web Almanac 2025: adoption, HTTP/3, TLS and DNS figures.
• Use image CDNs to optimize images on web.dev.