Iranian server or foreign? We measured 38 sites from outside

Method first, because a number without one is decoration

The site list came out of our own search data: domains ranking on page one of Persian Google for the commercial terms in this field. Each domain got three requests, redirects followed, a real browser user agent, and we kept the lowest time to first byte of the three. Lowest rather than mean, because one network hiccup ruins a mean and we wanted each server's best case.

Country came from the registered IP. Two responses were dropped because they came back under 20 KB, which is a challenge page or a redirect rather than a real page.

Measured from outside, the Iran-hosted median is a bit over three times slower. That is exactly what anyone would predict, which is why it is not the interesting number. The interesting one is that the spread inside each group is wider than the gap between the groups: within the Iranian set, the best site answered in 89 ms and the worst in 2319 ms. "Hosted in Iran" on its own tells you nothing about how fast a site is.

The limit on this table, stated rather than buried

We measured from Helsinki, not Tehran. The table therefore describes one audience: the visitor outside Iran. The mirror case is real and we cannot put a number on it, because we do not have a measurement point inside the country.

If someone shows you a table with precise figures in both directions, ask where the Iranian probe was and how many times it ran. That question usually has no answer.

Where our own site sits

On Hetzner in Helsinki, behind Cloudflare. In this same run, rgb.ir answered in 76 ms from that machine with 177 KB of HTML, and its IP is registered to Cloudflare.

We publish this because an agency that sells hosting and will not say where its own site lives is hiding something. It is the right call for a site with a four-language audience. For a shop whose customers all check out from inside Iran, the same call would be wrong.

So which one should you buy

The deciding factor is where your customers are, not where you are. All customers inside Iran, an Iranian payment gateway, no foreign audience: hosting inside Iran is the simplest answer and it works. A mixed or export-facing audience: a server abroad plus a content delivery network, and accept that the Iranian visitor waits a few dozen milliseconds longer. A brochure site with no online sales: this choice does not move your customer's decision at all, so spend the attention somewhere it matters.

One thing gets lost in every Iran-versus-abroad argument: neither option saves a three megabyte page. The heaviest page in this sample carried 3.1 MB of raw HTML before a single image or script. The median was 349 KB.

What we found while measuring

Opening the HTML to count how many other servers each page pulls from produced a pattern. The median page requested from 9 third-party hosts and the busiest from 34. That much is ordinary.

This was not: 22 of the 38 sites reference the eNamad trust seal domain in their HTML, and that domain does not answer from our network at all. Three attempts with a 30 second timeout never completed a connection, and a second external network refused it too.

Before calling that a crisis we looked at how the seal is actually embedded, and the answer is calmer than expected:

• 7 sites host a copy of the seal image on their own server. Nothing happens to them.
• 5 point at the eNamad domain directly but lazy-load it, so the request only fires if the visitor scrolls that far.
• 3 point at it directly with no lazy loading.
• 4 carry no seal tag in the initial HTML at all and presumably inject it with JavaScript.

The detail that matters: the seal is an image tag, not a script. An image that never arrives does not freeze the page, it simply never appears. So this is not a speed problem, it is a display problem, and it lands exactly where it hurts most. On the English version of your site, that empty rectangle is the spot that was supposed to build trust.

The obvious fix is to serve a copy from your own server, which is what those 7 sites already do. In fairness we could not check whether eNamad's own rules permit that, because their site does not open from our network. So we are reporting it as something other sites have done, not as advice we are standing behind. Ask them before you copy it.

Repeat this on your own site

It is one line and needs no tooling:

curl -o /dev/null -s -w "%{time_starttransfer}\n" -L https://example.com/

Run it three times, keep the lowest. If you run it from inside Iran, the number you get is what your Iranian customer actually experiences, and that number matters more than the table above. Our longer head-to-head of two Iranian providers is in the IranServer and ParsPack comparison, and the plans sit on the hosting page.

If your number is bad, look at page weight before you change host. In most cases we have seen, the server was not the culprit. Trimming the page down is cheaper than a migration and carries less risk, and when the current site is too heavy to be worth rescuing, rebuilding it is sometimes the shortest route.

Questions we get

Is Iranian hosting better for SEO?

Server location is not a ranking factor by itself. What counts is the speed a real user experiences. If all your users are inside Iran, a server inside Iran delivers that speed better, and the effect travels through the user, not through the geography.

Can Cloudflare give me a foreign server and still be fast for Iranian users?

Partly. Cloudflare publishes the list of cities in its network so you can see the nearest point to your audience. We took that route for our own site, but we have not measured it from inside Iran and we are not going to claim a figure we do not have.

Why the median instead of the average?

Because one 2319 ms site in this sample drags an average around on its own. The median describes the typical site more honestly.

How long does this measurement hold?

Until these sites change hosts. It was taken on 18 August 2026, and every repeat gets its own date on this page.