What Is a CDN?

A CDN, a content delivery network, is a set of servers spread around the world that hold copies of a site's files and deliver them from the point nearest whoever asks. Instead of fetching every image from a single server, it comes from a node a few kilometres away.

The gain is one of distance. Data travels fast but not instantly, and every round trip between continents costs noticeable time, especially in TTFB. Shortening the route is the most direct way to reduce it.

Besides bringing files closer, almost all CDNs do two more things: they absorb traffic spikes that would knock over the origin server, and they filter malicious requests before they arrive. For many sites that second job weighs as much as the speed.

It deserves separating from two things it gets confused with. It is not hosting: the site still lives on an origin server and the CDN sits in front. And it is not a backup: if the origin disappears, the nodes serve whatever they hold until it expires, and after that there is nothing.

Nor does it have to be bought as a separate product. Many hosts include one, and some CMS platforms switch it on with a checkbox. That is convenient and carries a trap: not configuring it yourself makes it easy not to know what is being stored or for how long — precisely the two questions that matter.

Here is the detail hardly anyone thinks about: with a CDN in front, there is no longer one answer. It depends on where the question comes from, whether that node held a copy, and how long it has held it.

For the visitor that is usually good. For whoever measures, not always: Google's crawler asks from somewhere else and at another time, so it can receive a different version from the one your customers see, faster or slower.

Google says it plainly in its documentation on multi-regional sites: most of its crawls originate in the United States, and it does not vary the location on purpose to detect variations. Anyone serving different content by region must signal it explicitly rather than trusting the search engine to notice.

A third factor changes the answer and appears on no dashboard: timing. A node that has just discarded its copy answers the first request slowly and the following ones quickly, so two measurements minutes apart can give opposite results without anything having changed.

That is why a single check says little. The field data in Search Console and in Core Web Vitals tools average real visits over weeks, and are therefore worth more here than any one-off test from a single location.

A CDN speeds up what can be stored: images, stylesheets, fonts, files that do not change between visitors. That improves the part of loading that depends on the network, and with it metrics like LCP when the largest element is an image.

What it does not speed up on its own is the time the origin server takes to build a page. If the HTML is generated afresh on every request, the CDN merely passes the question along and waits exactly as the browser would. An e-commerce shop that is slow because of heavy queries does not become fast by buying a CDN.

That is where the most widespread confusion sits: people expect an effect on Core Web Vitals that only arrives if the HTML is stored at the node as well. That is possible and it is done, but it is a separate decision with its own rules about which content visitors may share and which they may not.

The mobile side is worth a look, because that is where distance weighs most. On a slow connection every round trip costs considerably more than over fibre, so a shorter route shows up on mobile before it does on the desktop. An argument for the CDN that is rarely mentioned and is usually the strongest one.

And a precision about images: many CDNs convert and resize them on the fly. That genuinely helps, but it is a separate function from distribution, and it pays to check the result keeps the alt text and the dimensions declared in the HTML — if those are lost, the layout shift that CLS measures comes back.

First, check that headers survive the trip through the node. Some configurations forward only a known set and drop the rest, and then an instruction like the X-Robots-Tag exists at the origin and never reaches the crawler. Check the public URL, not the internal one.

Second, the logs. With a CDN in front, the origin server stops seeing most requests, so a log file analysis done there comes out incomplete; the useful logs become the CDN's own.

And third, the addresses. If static files move to being served from another domain, keep the certificate and the paths stable, because every domain change drags references along in old HTML, in external links and in the image sitemap.

A fourth point gets forgotten: redirects. Many CDNs let you define them at the node itself, which is fast and convenient and over time produces two rule lists — one in the CDN, one at the origin — that nobody compares. That is where the hardest to find redirect chains are born, because each half looks correct on its own.

And advice on working order: write down what is cached, for how long, and who may invalidate it. It is a setting made once and inherited for years; without that note, the next person seeing an out-of-date page will hunt for the cause in the CMS for hours before suspecting the node.

The first is buying one expecting it to fix slowness that does not come from the network. If the origin takes long to answer, the CDN delivers the images sooner and the visitor keeps waiting for the HTML.

The second is caching what should not be cached. A page with a user name, a basket or personalised prices served from cache ends up showing somebody another person's data; that is a privacy fault, not a performance one, and it happens more often than you would think.

And the third is forgetting invalidation. If the node keeps an old version for days, published changes reach neither visitors nor crawler — and that is almost always misdiagnosed: people look for the cause in indexing while the new content is simply not being delivered.

A fourth mistake is treating it as a final decision. Nodes, rules and plans change, and a configuration that was good three years ago may be caching things it no longer should. It deserves an annual review like any other piece of infrastructure.

And the last, the quietest of all: never checking from outside the office. The whole team works from the same city, over the same connection and probably at the same warm node; the experience measured there is the best of all possible ones. Real traffic arrives from places nobody on the team has ever tried.