Cloudflare For Iranian Sites: What It Actually Fixes

What we found on our own site

Our site sits behind Cloudflare and sends cdn-cache-control: max-age=2592000, which tells the network to hold the page for thirty days. Cloudflare's answer is this:

$ curl -sI https://rgb.ir/ | grep -i cf-cache-status
cf-cache-status: DYNAMIC

DYNAMIC means the page was not cached at all and every request travelled the whole way to the origin. We tried three different URLs and all three came back the same. Something we believed was switched on is not.

We are not writing that as a confession. We are writing it because it is the most common way a CDN fails: nothing looks broken. The site loads, the certificate is valid, every URL works and no error is logged anywhere. The only symptom is one word in one header that nobody reads.

One command that tells you where you stand

curl -sI https://example.com/ | grep -iE "cf-cache-status|x-cache|age:"

A HIT means the page came from the point nearest your visitor. A MISS means it did not this time but will from now on. A DYNAMIC means it never will, and the network is passing traffic through without storing anything. The distinction between MISS and DYNAMIC is where most people go wrong: the first is temporary, while the second means your cache rule does not match that page at all.

How many Iranian sites use a CDN

On 15 August 2026 we read the response headers of 38 Iranian sites. The distribution:

Twenty-seven of the 38 answer straight from their own server. That is not automatically a mistake, and the reason why comes further down.

The number we do not have, and nobody has published

Your real question is which one is faster for a visitor inside Iran, and the honest answer is that we cannot measure it.

Our server is in Helsinki. Timing ArvanCloud and Cloudflare from here measures the distance to Helsinki, not what somebody in Tehran experiences. You get a number, it looks convincing, and it is useless.

So when you see an article with a CDN speed comparison table aimed at Iranian users that does not say where the measurement was taken from, it probably has this exact problem and the author did not notice. Measuring this properly needs probes inside Iran, and we do not have them.

What a CDN definitely does solve

Four things can be stated without any geographic measurement, because they are about architecture rather than distance.

Load on the origin. When static files are served from the edge, your server only sees dynamic requests. On shared hosting that difference is real, and how hosting configuration shows up in speed and SEO numbers covers how it surfaces in the measurements.

Survival during an outage. If the origin goes down and the page is cached at the edge, visitors still get the page. This only works when caching is genuinely on, which brings us back to that header.

Bandwidth. Image and file traffic leaves your server, and on hosting plans with metered bandwidth that converts directly into money.

Certificates and protocol. The network usually brings the newest protocol version and automatic certificates even when the origin is old.

And what it does not solve

A site that sends 400 KB of HTML sends the same 400 KB from behind any network in the world. A CDN does not reduce weight, it shortens the distance the weight travels.

The same goes for a slow database query, a plugin that rebuilds the page on every request, and an image uploaded at full camera resolution. All of them survive the move untouched. If your Core Web Vitals numbers are poor because of heavy JavaScript, a CDN changes nothing at all.

When not to bother

If your entire audience is in one Iranian city and your server is in Iran too, a foreign CDN probably lengthens the path rather than shortening it. Traffic that could have travelled a few dozen kilometres crosses a border and comes back.

The second case is sites that are almost entirely dynamic, like a customer panel or a checkout. There is nothing to cache, so the network only adds one more layer between user and server.

One practical warning as well. If you add a CDN, revisit your site's own cache layer. Two caching layers that do not know about each other will keep a change you made hidden from some visitors for hours, and you will think the save failed.

Questions people ask

Is the free Cloudflare plan enough? For most small sites, yes. The difference between free and paid is mostly advanced rules and support, not proximity to the user.

Does a CDN affect SEO? Indirectly. Google awards nothing for where you are served from, but a page that arrives sooner produces better page experience numbers. The effect runs through speed, not through the network itself.

Why did my site get slower after I turned it on? Usually because caching is not actually active and you have only added a middleman. Run the command above; a DYNAMIC is your answer.

If you want to know where your site's speed is genuinely losing time, and whether a CDN is even your problem, that is not settled by guessing but by measuring before and after, which is exactly what speed optimisation with a before-and-after report is. For a site not yet on suitable infrastructure, hosting configured properly is the better starting point, because a CDN hides a slow server rather than fixing it. And if the site itself was built heavy, no layer substitutes for building a light site from the start.

The headers of 38 sites and our own cache status were read on 15 August 2026 and are repeatable with the command above. Our cache status may well be corrected by the time you read this; that was the reading on the day.