What a CDN is
A CDN is a network of servers in different places around the world that keep copies of your site files so every visitor is served from the nearest point. The most important thing that usually goes unsaid is that by default a CDN keeps images, fonts and static files and not the pages themselves; whether your pages stay at the edge too is a separate rule that you have either defined or not.
- Lesson 8 of 12
- Beginner
- Free, no signup
One origin, dozens of copies, and a visitor served by the nearest
The origin
one place, and the only source of fresh content
- The site really lives here
- Every change happens here first
- Requests for pages usually come all the way here
The visitors
anywhere in the world, each with their own distance
- The further away, the larger the share of travel time
- They get images and fonts from nearby
- Their browser also has a separate cache of its own
when the edge node holds the copy, the origin never even learns that somebody came
The edge nodes
dozens of points that only keep copies
- They never produce fresh content
- They decide by their default rule, not by your wish
- They hold a copy for as long as they consider it fresh
This drawing shows the path of something the edge is holding. Pages are not among those by default and only pass through the middle once an explicit rule says so.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What does a CDN actually do?
Your site sits on one server, in one particular city. A visitor in that same city and a visitor on the other side of the world both have to reach that one machine, and the second has no choice but to bear the distance. A CDN shortens that distance with a simple trick: it keeps copies of the files in dozens of places around the world and sends each request to the nearest one.
Two terms are needed and the rest is detail. The origin is the machine the site really lives on and the only place fresh content ever comes from. An edge node is one of those dozens of points, and it only keeps copies. When an edge node has something, it answers by itself and the origin never even hears about it.
The main benefit is right there, and it is twofold. For the visitor, the path gets shorter. For you, the load on the server drops, because every file the edge answered is a request that never reached your machine. On this site, when we measured one font file, the edge had been holding its copy for 96 hours and in all that time had not asked our server for it once.
What really stays at the edge, and what does not?
This is where most site owners assumption fails to match reality, though not in the way you might expect. The common assumption is that putting a site on a CDN means the pages are served from the nearest point. By default that sentence is false, and wherever it is true it is because somebody defined an explicit rule for it.
The default decides on the file extension and not on the content type. The provider this site sits behind publishes, in its own documentation, the list of extensions it keeps by default: images, fonts, style files and scripts are on it, and HTML pages explicitly are not. So a site that has just gone behind a CDN has its files at the edge and its pages not.
On this site that rule was added, and the result is measurable. We took five different addresses and all five answered from the edge; the age of the front page copy went from 126 to 127 seconds between two consecutive requests, meaning the edge is handing out its own stored version and never going to our server at all. In the same moment a font file with a copy 96 hours old and an image with a copy 174 hours old, which is more than seven days, answered from the edge too.
Another piece worth seeing: the pages of this site send two different cache headers to two different audiences. They tell the browser to ask again every time, and they tell the edge to hold it for thirty days. Those are not contradictory; they are two different recipients, and that is what lets one page stay at the edge and stay fresh for somebody who has signed in.
And now the trap that eats an afternoon and is written almost nowhere: if you check with a HEAD request you get the wrong answer. On this very front page a HEAD request says the content was treated as dynamic, and a GET request to the same address in the same moment says it came from the edge. The reason is that the cache rule covers GET requests only. If you are ever certain your pages should be cached and the header says otherwise, suspect the shape of your own request before you suspect the settings.
The decision the edge makes for every request
Is this one of the things the edge keeps by default?
Answered from the edge
- Images, fonts and light files: their extension is on the default list
- The origin does no work at all
- On this site the copies were 96 and 174 hours old
By default it travels to the origin
- The pages themselves: not cached by default
- Without an explicit rule, every visit is a full request to your machine
- On this site that rule was added, so the pages come from the edge too
This is the default decision and an explicit rule changes it. The default behaviour also differs from one provider to the next, so the only authority is the response header of your own site.
What difference does it make for an Iranian visitor to a foreign site?
The logic is simple and the effect is asymmetric. The further a visitor is from the origin, the larger the share of time spent travelling back and forth, and that is exactly the case where a nearby copy pays most. For a visitor in the same city as the server, the edge adds almost nothing.
But half the story is the previous section. If no rule was defined for the pages, that distant visitor still travels to the origin for the page itself and only gets the images and fonts from nearby. If one was defined, the page comes from the edge too, and that is exactly where most of the benefit appears. So the size of the gain depends on a configuration decision rather than on having bought the service.
Now let us say honestly what this lesson does not know. We cannot measure what path a visitor inside Iran takes or which edge node answers them, because this server is in Europe and any measurement from here shows only its own path. Any number a tutorial gives you about CDN speed from Iran is fabricated unless it was taken from inside Iran. The only valid test is for you or one of your users to measure from where you actually are.
When does a change you make reach the visitor?
This is the most practical part of the whole subject and the place where new teams waste the most time. The short answer: anything sitting at the edge does not change for as long as the edge considers it fresh. And if your pages are cached too, that includes the pages themselves; the edit was made on the server and the visitor is still seeing the previous version.
The reason has already been given above. The static files of this site are cached with a one year permission and, as you saw, one of them is holding a copy 174 hours old right now. If you replace that file under the same name, the edge has no reason to ask again; as far as it is concerned its copy is still fresh. The pages are sitting at the edge too, with a thirty day permission. And the visitor browser has a cache of its own, which is outside your reach entirely.
For static files the professional answer is not clearing the cache, it is changing the name. If the address of the file changes, it is no longer the same file and everyone starts over. On this site the plugin files carry a version number in the address, and that one small rule is the difference between changing something and nothing happening, and changing something and seeing it at once. Let us be blunt because we have paid for it ourselves: an edit to the style file of a plugin, without raising the version number, changes practically nothing for a visitor. For the pages themselves that trick is not available, because the address of a page is what Google has on record and changing it is a loss in itself; there the only route is a targeted purge of those few addresses.
And about clearing the cache, a warning the advertising leaves out. Clearing is not free. Every page thrown out of the cache has to be built again, and if you clear the whole site at once all of that building arrives at your server together. On a server that hosts several sites, one badly timed site wide purge can slow all of them down at the same moment. Our rule is this: clear only the addresses that actually changed.
The life of one change, from the edit to the visitor eye
-
1
You replace the file on the server
From this moment the origin has the new version. The only place that does.
-
2
The edge still holds the old version
And it has no reason to ask again, because as far as it knows its copy is fresh.
-
3
The visitor browser holds the old version too
This one is outside your reach and no clearing on your side empties it.
-
4
Change the file name, and it is done
A new address means a new file, so everyone starts over. This replaces clearing the cache and its risk is zero. For pages themselves the route is not available.
This order is for a static file. The same happens to a page that is sitting at the edge, except that the address of a page cannot be changed and the only route is a targeted purge of that address.
When is a CDN not worth it for you?
Let us take a clear position, because almost no source says this. If all your visitors are in one country and the origin is in that same country, a CDN adds little to their speed and can even add one more station to the path of the page. In that case you are paying its money and its complexity for something other than speed.
That does not mean it is useless, and people who treat a CDN as only a speed tool have seen half the story. Three other benefits are independent of distance: absorbing abnormal traffic before it reaches your server, serving static files without putting load on the main machine, and handling the certificate and the secure connection at the edge. For many sites that second one alone is worth it.
And three real costs to accept with open eyes. One more layer is added to debugging, and from now on when something breaks you have to ask whether it is the server or the edge. Changes arrive late: a static file until its name changes, and a page until that address is purged. And the default behaviour of every provider differs from the next and changes over time, so the only trustworthy source is your own response header rather than something you read somewhere six months ago.
If the bottleneck of your site is building the page rather than the distance, the right work is elsewhere and continues in the site speed track.
The fast path, with AI
The ordinary way to find out what a CDN is doing is to open its panel and look at the settings. The fast way is the opposite: ignore the settings and take the real headers of a few addresses from your own site, because a setting says what was asked for and a header says what happened. That single audit, which takes ten minutes, usually reveals two or three things the site owner believed were otherwise.
- Take six addresses from your own site that are a real sample: the front page, an inner page, a blog post, an image, a style file and a font.
- Take the headers for each with a GET request and not a HEAD: curl -s --compressed -D - -o /dev/null https://example.com/path. The reason is in section two and the whole audit hangs on it. Three lines of each response matter and the rest can be thrown away: the edge cache status, the age of the copy, and your own cache header.
- Hand all six over together with the recipe below, not one at a time. The entire value of this is in comparing the rows: when the pages say one thing and the files say another, the pattern shows itself. A fast, cheap model is enough; the current pick in each class is kept in our AI reference.
- Turn the answer into a decision rather than a report. If the static files have a long life and their names are not versioned, that is the most important thing to do this week.
Copy-ready recipe
You are a caching and content delivery specialist. Judge only from the table below. Do not add any provider default behaviour from your memory.
For each address, three things are taken from the response header: the edge cache status, the age of the copy in seconds if present, and the cache header the site itself sends.
1. Front page: {status} | {age} | {cache header}
2. An inner page: {status} | {age} | {cache header}
3. A blog post: {status} | {age} | {cache header}
4. An image: {status} | {age} | {cache header}
5. A style file: {status} | {age} | {cache header}
6. A font: {status} | {age} | {cache header}
Write five things:
1. Which rows were really answered from the edge and which travelled to the origin. Group the rows.
2. Whether pages and files behave differently. If so, state the pattern in one sentence.
3. Whether the cache header the site sends matches what the edge did. Name every place it does not.
4. For each row, write: if I replace this file right now under the same name, when does a visitor see the new version.
5. One action, only one, with the largest effect.
Rules: the edge cache status has more than two possible values; quote a value you do not recognise verbatim and do not invent a meaning for it. Invent no number and assume no header that is not in the table. If the age is missing for a row, write "not reported" and draw no conclusion from it. Do not propose clearing the whole cache.Before you trust the output: One rule you have to keep yourself, even if the answer says otherwise: clearing the whole cache is the last move, not the first. If your problem is that a change to a file is not visible, the answer is versioning the name rather than emptying the cache of the entire site, because next time the same thing happens again. And if your site shares a server with several others, one site wide purge at a busy hour slows all of them down together. For checking, only the few addresses you actually changed are enough.
AI in this kind of work
This subject is one where a language model has two completely different behaviours and you need to know the difference. Put the real headers in front of it and it is excellent: it finds the pattern across a few rows, sees the contradiction between what the site asked for and what the edge did, and says in seconds what takes half an hour to read by hand. Put nothing in front of it and merely ask what the default behaviour of some service is, and it answers from memory, and its memory has a date.
Tools that actually help
- Claude Good for handing over several sets of headers at once and asking for the pattern, exactly the job in the fast path above. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini Notebook This is the right way to ask about the default behaviour of a service: upload the documentation page of that service itself and ask the question inside that document. The answer comes from the provider own text, and the update date of that page is in front of you. It runs on a Google account, and Iran is not among the available regions.
Where it backfires
Two specific risks, both happening in this exact topic. First, the model states the default behaviour of a service from memory. This is a field where the rules differ between providers, differ between plans of the same provider, and change over time; the documentation page this very lesson leans on carries its own last updated date, which is exactly why a model memory is not enough here. Anthropic itself calls saying something untrue with confidence hallucination in its documentation. Second and more expensive: the model proposes clearing the entire cache as the remedy, because that is the most common answer written on the internet. On a server hosting several sites that is a costly operation, and it does not fix a problem that usually comes from file names not being versioned. Our position: the model is allowed only to read headers you collected yourself, and the default rule has to be read on the provider own documentation page rather than from the model.
Sources: Cloudflare: default cache behavior Cloudflare: CDN-Cache-Control Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
Everything this lesson measured comes from one site behind one particular provider. Default rules differ between providers, differ between the plans of one provider, and change; so what transfers here is the method, meaning looking at the real response header, rather than the list of extensions. The second boundary matters more: this server is in Europe and we cannot judge what path a visitor inside Iran takes, which edge node answers them, or whether an edge is reachable for them at all. No number about the experience of a visitor inside Iran appears in this lesson, because we have none. And one last thing is deliberately left out: configuring cache rules on a specific service, which depends on that service panel and whose documentation is the only correct authority.
From our own work
The numbers this lesson is built on come from the response headers of this very site, on 7 September 2026. We took five HTML addresses with a GET request, the front page, a service page, a blog post, the English version of the front page and one more page, and all five answered from the edge; the age of the front page copy went from 126 to 127 seconds between two consecutive requests, which means the edge is handing out its own stored version. In the same minute a font file with a 96 hour old copy and an image with a 174 hour old copy answered too, both served with a one year cache permission. And the thing this session paid for itself, which is the best lesson on this page: the first time we ran this check we ran it with a HEAD request, and all five pages said they were not cached. With GET, the same five addresses in the same moment said they came from the edge. The cache rule on this zone covers GET requests only, so a check made with HEAD returns the opposite answer and no settings panel tells you so.
Real follow-up questions
Will a CDN make my site fast?
Part of it, and which part depends on a configuration decision. If no rule was defined for the pages, the time to the first byte stays roughly what it was and only images and fonts arrive sooner. If one was defined, the page comes from the edge too and that is where the difference becomes noticeable. But for a site whose page is slow to build, a CDN does not even move the problem.
I changed the style of my site and nothing happened. Why?
Because the address of the file did not change, and both the edge and the visitor browser still consider the old copy fresh. If that file was cached with a long permission, the situation can go on for days. The right answer is not clearing the cache; it is adding a version number to the file address so that the address changes whenever the content does.
How do I tell whether my page was answered from the edge or from my own server?
From the response headers, not from the settings panel, and with a GET request. Look for two lines: the edge cache status, and the age of the copy; if an age is reported, the edge is holding a version and telling you how long. And let us repeat the most important point, because we walked into it ourselves: do not run this test with a HEAD request. On this site one address says with HEAD that the content was treated as dynamic, and the same address with GET, in the same moment, says it came from the edge.