When Does a CDN Actually Make a Website Faster?

A client once asked me to “add a CDN” because their site felt slow. The site was a small online shop, the server was in Frankfurt, and almost all their customers were in Germany and Austria. I put Cloudflare in front of it on a Tuesday afternoon, ran the same tests I’d run that morning, and got almost exactly the same numbers. Largest Contentful Paint moved by maybe 80 milliseconds. The client was disappointed, and honestly, so was I.

Two months later the same client started selling to Australia. Then the CDN made a huge difference. Pages that had taken over four seconds to become usable in Sydney dropped to under two. Same CDN, same configuration, same site. The only thing that changed was where the visitors were.

So does a CDN make a website faster? Sometimes a lot, sometimes not at all. Which one you get depends on three things you can check before you set anything up: how far your visitors are from your server, what share of your page can be served from cache, and what’s actually slow about your page right now.

What a CDN actually speeds up

A CDN is a network of servers in many cities. Visitors connect to the nearest one instead of your origin server. That helps in two concrete ways.

It shortens the round trips before anything arrives. Before a browser can receive the first byte of a page over HTTPS on a new connection, it needs a DNS lookup, a TCP handshake, a TLS handshake, and then the actual request. That’s roughly three network round trips with TLS 1.3, more with older setups. From Frankfurt to Sydney, a round trip is on the order of 250 to 300 milliseconds. Three of them is most of a second spent on waiting, before your server has done any work. If the visitor instead connects to a CDN node in Sydney, those handshakes take a few milliseconds each.

It serves cached files without asking your server. Images, CSS, JavaScript, and fonts that the CDN has cached come straight from the nearby node. For a page with 40 static files, that’s 40 responses that don’t have to cross the planet.

Both of these benefits are about distance. If your visitors are already close to your server, there’s not much distance to remove. That’s why my German shop barely changed: the round trip from Munich to Frankfurt is around 10 milliseconds. Cutting that to 3 doesn’t change what anyone sees.

When a CDN makes a real difference

Your audience is far from your server

This is the main case. If a meaningful share of visitors are on another continent, a CDN reduces connection setup time and static asset delivery time for them. My Australian visitors saw time to first byte on static files drop from around 900 milliseconds to around 40. Their pages felt like a different site.

Your pages are mostly static assets

A page that’s 50 KB of HTML and 2 MB of images, scripts, and fonts gets most of its bytes from files a CDN can cache. The more of your page weight is cacheable, the more a CDN can help, especially for visitors far away.

The whole page can be cached

For a blog, docs site, marketing site, or anything built by a static site generator, the HTML itself is the same for everyone and can be cached at the edge. Then even the first request never touches your server, and time to first byte is fast everywhere. This is where CDNs look best in benchmarks, and it’s why static hosting platforms are all built on one.

Your server is struggling under load

If a traffic spike is slowing your origin down, a CDN absorbing most of the static requests frees your server to handle the dynamic ones. The site gets faster for everyone, not because the CDN is close to them but because your server has less to do. This is about capacity rather than distance, but the result shows up as speed.

When a CDN barely helps

Your visitors are near your server

As with my German shop. If 90 percent of traffic comes from the same region as your server, a CDN won’t make a visible difference for most people. It may still be worth having for other reasons (DDoS protection, free TLS, absorbing spikes) but don’t expect a speed improvement.

The slow part is your server generating the page

This was the shop’s real problem, and the CDN couldn’t touch it. Product pages were built dynamically, uncached, and took about 1.2 seconds on the server because of slow database queries and a plugin that called an external API on every page load. The CDN passed those requests through to the origin, so they took 1.2 seconds plus network time, exactly as before.

If your time to first byte for HTML is slow even when you test from next to your server, the problem is in your backend, and a CDN won’t help. Fix the queries, cache the rendered page on the server, or make the page cacheable at the edge. The first two are server work. The third depends on whether the HTML differs per visitor, which is a bigger design question. It’s also where people start asking whether to run the dynamic part at the edge too, and when edge compute beats a plain VPS depends mostly on where your data lives, not on how many cities the network covers.

The slow part is in the browser

A CDN delivers bytes faster. It doesn’t make them smaller or quicker to run. If your page ships 1.5 MB of JavaScript that takes two seconds to parse and execute on a mid-range phone, the CDN saves you a few hundred milliseconds on download and nothing on execution. The same goes for render-blocking scripts, huge unoptimized images, and web fonts that hold up text rendering. On the shop, the largest element on product pages was a 1.8 MB hero image. The CDN delivered it faster; it was still 1.8 MB.

Some CDNs offer image resizing and format conversion, which does help here, but that’s a separate feature you have to turn on and configure. Putting a CDN in front of your site doesn’t do it by default.

Your cache hit ratio is low

A CDN only saves time on responses it actually has cached. If assets have short cache lifetimes, if every deploy changes URLs without cache-busting done right, or if your traffic is spread thinly across many regions and pages, lots of requests miss the cache and go to the origin anyway. A cache miss through a CDN is sometimes slightly slower than going direct, because there’s an extra hop. Check your CDN dashboard’s hit ratio before assuming it’s helping.

How to tell in advance whether a CDN will help you

You can answer this in about an hour, before changing anything.

1. Check where your visitors are. Your analytics will show country or region. If most traffic comes from near your server, expect a small speed gain. If a significant share comes from other continents, expect a big one for them.
2. Test from far away. Use WebPageTest or a similar tool to load your site from a location near your server and from one on the other side of the world. Compare connection setup time and time to first byte. The difference between the two is roughly what a CDN can recover.
3. Split the page into cacheable and dynamic. Look at the waterfall. How much of the load time is static files, and how much is waiting for the HTML? A CDN helps the first part directly. It only helps the second if the HTML can be cached.
4. Test time to first byte from near your server. If the HTML is slow even from close by, fix the backend first. A CDN won’t.
5. Look at what the browser is doing. Lighthouse or Chrome DevTools will show you long JavaScript tasks, render-blocking resources, and oversized images. If those dominate, a CDN is not your first fix.

What I did for the shop

The order of fixes ended up being the reverse of what the client first asked for.

• Backend first. We removed the plugin that called an external API on every page view and added an index to the slowest product query. Server time for product pages dropped from 1.2 seconds to about 200 milliseconds. That helped every visitor, everywhere.
• Images second. The hero image went from 1.8 MB to about 150 KB in a modern format at the right size. Largest Contentful Paint for German visitors improved by over a second, more than the CDN had ever done for them.
• CDN kept for assets. Static files with long cache lifetimes and versioned filenames, served from the edge. This is what made the Australian launch work.
• HTML still from origin. Product pages show stock levels and prices that change, so we didn’t cache the HTML at the edge. For Australian visitors, that first request still crosses the world, but the connection is set up with the nearby CDN node, which reuses a warm connection to the origin, so it’s noticeably faster than going direct.

The short answer

A CDN makes a website faster when there’s distance to remove and content it can cache. It does very little when your visitors are nearby, when your server is slow to generate pages, or when the browser is the bottleneck.

If your audience is local and your site feels slow, measure before you add a CDN. You’ll probably find the delay in a database query or an oversized image, and fixing those helps every visitor. If your audience is global, a CDN is one of the cheapest large improvements you can make, as long as it’s actually serving from cache.