If your visitors are in Iran, the work to reduce website latency usually starts where hardly anyone looks: the map. You have optimized the site, compressed the images and switched on caching, yet the page still hesitates before it appears? Before you go back to the code, ask one question: where is the server? This guide explains what ping and TTFB really are, how many round trips a single visit costs, how to measure them, and why the location of the data center is the biggest lever you have.
What is ping, and what does website latency mean?
If you ask what ping is, the simplest answer is: the time of one round trip. Your computer sends a small packet to the server, the server replies, and the duration of that round trip is recorded in milliseconds. This number is also called RTT, or latency; MDN's definition of RTT says exactly that: the time it takes a packet to reach its destination plus the time for its acknowledgement to come back.
Think of a food delivery courier: however fast the restaurant is, if the courier has to come from the other side of town, the round trip sets the minimum delivery time. Opening a web page isn't a single round trip either; it is several in a row:
- DNS — translating the domain name into an IP address (at least one round trip if the answer isn't cached);
- TCP — the initial handshake with the server (one round trip);
- TLS — setting up the secure HTTPS connection (usually one or two round trips);
- HTTP — sending the request and receiving the first byte of the response.
Add these up, plus the server's processing time, and you get TTFB (Time To First Byte): the gap between the user's click and the first byte of HTML. So every millisecond of ping is multiplied roughly four times in TTFB; website latency piles up faster than you would expect.
Alongside the average, watch two other numbers: jitter, how much that same number varies from one packet to the next, and packet loss. A steady 90 ms ping makes for a better experience than one that jumps between 40 and 200. Also keep in mind that ping uses ICMP, not HTTP, so it only shows the "floor" of a path's latency.
Why physical distance and routing have the final say
Light travels through optical fiber at about 200,000 km per second — two thirds of its speed in a vacuum, because the refractive index of fiber glass is close to 1.5. A rule of thumb follows from that number: every 100 km of path adds about one millisecond to the round trip. The fiber route from Tehran to Frankfurt (which is never a straight line) is roughly 4,000 to 5,000 km, so the physics of the round trip alone costs 40 to 50 ms, before any queue and before any congestion. That is the theoretical floor, and no software optimization can break it.
In practice the real number is worse: traffic passes through dozens of routers (hops), queues at Iran's international gateway — the limited set of border links that carry the country's traffic to and from the rest of the world — and at peak hours competes with all of the country's other outbound traffic. The result? A ping of 90 ms at noon becomes 150 at night, with high jitter. A server inside the country, by contrast, means a short path, few hops and negligible jitter.
The surprising part is that the internet picks routes according to operators' peering policies, not the shortest line on the map — which is why switching operators can sometimes make a difference of 20 to 30 ms without anything moving geographically.
How many round trips does a single visit cost?
The budget of a fresh visit with nothing cached:
| Stage | Round trips needed | At 15ms ping | At 120ms ping |
|---|---|---|---|
| DNS lookup (not cached) | 1 or more | 15ms | 120ms |
| TCP handshake | 1 | 15ms | 120ms |
| TLS 1.3 handshake | 1 | 15ms | 120ms |
| TLS 1.2 instead | 2 | 30ms | 240ms |
| HTTP request to first byte | 1 + server processing | 15ms + | 120ms + |
| Total to first byte with TLS 1.3 | 4 | about 60ms | about 480ms |
The last column is what a user in Iran experiences on a server in Europe: nearly half a second of silence before the first byte arrives. web.dev's guide to TTFB recommends keeping TTFB under 0.8 seconds; on a high-latency path, most of that budget is burned before a single line of your code has run.
Measure latency: ping, mtr and curl
Don't guess; measure. The simplest tool is ping:
ping -c 5 example.com
PING example.com (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=118 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=54 time=121 ms
64 bytes from 203.0.113.10: icmp_seq=3 ttl=54 time=117 ms
64 bytes from 203.0.113.10: icmp_seq=4 ttl=54 time=131 ms
64 bytes from 203.0.113.10: icmp_seq=5 ttl=54 time=122 ms
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 117.412/121.905/131.044/5.104 msRead the last line: min is the closest thing to pure propagation delay, because queueing noise has been filtered out of it; mdev is the jitter, and if it climbs above ten percent of the average, your path is congested. Any non-zero packet loss matters more than every other number in this output.
Find the guilty hop with mtr
To see the whole path, use mtr — a combination of ping and traceroute. On Ubuntu and Debian install it with sudo apt install mtr-tiny, and on Rocky and Alma with sudo dnf install mtr:
mtr -rwzc 20 example.com
HOST: workstation Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.1 0.0% 20 0.9 1.0 0.7 2.1 0.3
2. AS58224 10.21.4.1 0.0% 20 6.4 7.1 5.9 14.2 1.8
3. AS58224 tehran-core-1.example-isp.ir 0.0% 20 9.8 10.4 9.1 19.7 2.2
4. AS49666 border-gw.example-transit.net 0.0% 20 11.2 12.0 10.6 21.3 2.4
5. AS49666 fra-ix.example-transit.net 0.0% 20 114.7 118.9 113.2 141.5 6.9
6. AS24940 core.example-dc.de 0.0% 20 116.1 119.4 114.0 138.8 5.7
7. AS24940 203.0.113.10 0.0% 20 117.4 121.9 117.1 131.0 5.1This output tells a complete story: up to hop four we are inside Iran and latency is below 13 ms; between hops four and five the number jumps from 12 to 119 — exactly where traffic crosses the international gateway — and nothing is added after that. No setting on the destination server will win back that 107 ms jump.
Measure what the user feels: check TTFB with curl
ping gives you network latency; curl shows the real TTFB:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
" https://example.com/
DNS: 0.0043s
TCP: 0.1261s
TLS: 0.2588s
TTFB: 0.4102s
Total: 0.9873sThese numbers are cumulative, not independent; to get each stage's share, you have to subtract. Here DNS was nearly free (a cached answer), TCP took about 122 ms — which means the path's ping is about the same — TLS another 133 ms, and the stretch from the end of TLS to the first byte 151 ms, which is one round trip plus the application's processing time. So three quarters of this page's TTFB was the cost of distance, not slow code. To isolate the network's share, run the same command on the server itself against 127.0.0.1.
For an outside view of the site as a whole, the free website speed test takes several samples and reports the median TTFB, the redirect chain, page weight and SSL status. One honest note: this tool sends its requests from Mehran Host's own server outside Iran, so read its figures as a before-and-after comparison for your own site, not as the experience of a visitor in Iran.
| Symptom | Likely cause | Next step |
|---|---|---|
| High but steady ping, low mdev | The physical floor of the path and geographic distance | Move the server closer to your audience; tuning won't help |
| Good ping but high TTFB | A slow application or database, not the network | Run the same curl against 127.0.0.1 and compare |
| Fluctuating ping and high mdev, at night | Congestion and queueing at the international gateway | Use mtr to find the hop where the jump starts |
| Packet loss from one hop all the way to the destination | A faulty link or device on the path | Send the mtr output to your operator |
| A large gap between time_connect and time_appconnect | An old TLS version, or no session resumption | Enable TLS 1.3 and session resumption |
Reduce website latency in Iran by choosing the right data center
Real-world numbers for a user inside Iran look roughly like this:
| Server location | Typical ping from Iran | Approximate TTFB (HTTPS) | Jitter |
|---|---|---|---|
| Iranian data center | 1 to 20 ms | Under 100 ms | Very low |
| Europe (Germany, Netherlands) | 80 to 150 ms | 400 to 700 ms | Medium to high |
| North America | 150 to 250 ms | Over 700 ms | High |
In other words, for an audience inside Iran, moving the server from Europe into the country can on its own make TTFB four to seven times better — something no caching or compression plugin can do.
We have exact figures for each location as well: we measured ping to Germany, Finland, the US East and West Coasts and Singapore from a server in an Iranian data center, and the full table, along with the packet paths, is in our guide to the best VPS location for Iran by real ping.
One caveat: the ping figures above apply to fixed-line connections. On mobile internet, much of the latency is created in the radio network, and 30 to 70 ms is normal even to a server in the same city; before you blame the data center, test from a fixed line as well.
What these numbers mean for SEO and sales
Google measures response speed directly in its Core Web Vitals. web.dev's LCP documentation states explicitly that connection time, redirect time and TTFB delays are counted inside the LCP figure, and that the "good" threshold is 2.5 seconds; so the half second we burned on the round-trip budget, before anything was rendered, comes straight out of that allowance. Cutting server latency here acts directly on that number.
When the ping looks good but the experience is bad
Sometimes the average ping looks respectable and users still complain that the site is slow. The first suspect is queueing in intermediate equipment: when a link is saturated, packets queue up in routers' large buffers. Diagnosing it is simple: run ping during a heavy download; if the number jumps from 20 to 300, the problem is your link's capacity, not the server. The second suspect is packet loss: one percent sounds harmless, but TCP makes up for every lost packet with an extra round trip and shrinks its send window.
And the third suspect has nothing to do with your server: the page itself. If the theme points to fonts and scripts on foreign domains, the browser travels a separate, high-latency path for each of them — even if your server is inside Iran. How to remove those dependencies is covered in our guide to a website slow in Iran on the national internet (NIN), the country's domestic network.
Which server settings actually cut round trips?
When you can't shorten the distance, the only option left is to reduce the number of round trips. The list, in order of impact:
- Remove redirect chains. The most expensive problem and the easiest win; put the final destination directly in your links.
- Enable TLS 1.3 and turn on session resumption. A TLS 1.3 handshake takes one round trip, TLS 1.2 takes two. For a returning user, resumption with a pre-shared key lets data travel in the very first packet — a feature that RFC 8446 defines as 0-RTT, warning in the same place that it is not protected against replay; so use it only for safe requests such as GET.
- Keep connections alive. keep-alive and HTTP/2 multiplexing mean dozens of files travel over one existing connection, without repeating TCP and TLS for each of them.
- OCSP stapling is only worth it if your certificate has OCSP. This setting removes one browser round trip to the issuer's server, but Let's Encrypt removed the OCSP URL from new certificates in May 2025, shut down its responders in August 2025 and moved to CRLs; on a certificate like that, stapling has nothing to save.
- Reduce the number of domains on the page. Every new host in the HTML means one DNS lookup and one fresh connection; hosting fonts and libraries locally removes several round trips.
The hands-on configuration for these items is in our guide to install Nginx on Ubuntu and set up a website. And note what is not on the list: no kernel tweak and no "network optimizer" reduces propagation delay; they affect throughput, not the round-trip floor.
HTTP/3 and QUIC in Iran: how much do they really cut latency?
On paper, QUIC was built for exactly this problem: it merges the transport and encryption handshakes into a single step, so a new connection needs one round trip fewer. RFC 9114 is the official HTTP/3 standard, and on lossy paths it has a second advantage: because every stream is independent, one lost packet doesn't stall the rest.
But here is what we measured in the field: in our test from a host inside Iran, QUIC v1 handshakes to servers outside the country went unanswered and timed out after 10 seconds, while TCP to the same IP and port got a 200 response in under a second; the same behavior repeated with several large global services. It isn't a UDP port block — a QUIC packet with an unknown version gets an immediate answer — only real version 1 handshakes disappear.
When is a server abroad still the right choice?
The location of the data center should follow where your audience is, not personal preference. A server abroad makes sense when:
- Your audience is outside Iran — a site for users in Europe should be hosted in Europe; the same logic of distance, this time in the foreign server's favor.
- You depend on foreign services — if your backend constantly talks to APIs that respond slowly from inside Iran, being close to those services matters more.
- Your workload isn't a website — some processing jobs have no end users inside Iran at all.
The professional answer is often a hybrid: the main site on a server inside Iran, plus a small server abroad just for those specific jobs — a setup that stays under control with hourly billing, as we explain in our guide to the hourly billing cloud server; our comparison of Iran hosting vs foreign hosting sums up the same decision with a selection table. Define the criterion precisely: not the average of all your visits, but the audience of the pages that make money.
A CDN is a complement, not a replacement
You may be asking: "Won't a CDN solve this?" Partly. A CDN caches static files — images, CSS, JavaScript — on edge nodes close to the user, and for that category it is excellent, but it has two important limits:
- Dynamic requests still go to the origin. A product page, the shopping cart and anything else that touches the database has to travel all the way to the main server and back — with the same high ping.
- The first byte of HTML usually comes from the origin. That means the very TTFB that Google and your users measure is still held hostage by the main server's distance.
A less discussed subtlety: when a request is a MISS on the edge node, the user pays for "user to edge" plus "edge to origin" — so for the first visitor to each file, a CDN can be slightly slower than a direct connection, and the real gain comes from the HITs that follow. How edge caching works is explained in our complete guide to what a CDN is.
The right formula is: an origin close to your audience + a CDN for static assets + a well-tuned web server. If the origin and the edge node are both inside Iran, neither the HIT path nor the MISS path ever leaves the country — the most stable combination for an audience inside Iran.
Migrating your server without downtime: the order of steps
- Lower the A record's TTL to 300 seconds and wait for as long as the previous TTL.
- Bring the site up on the new server and, before changing DNS, test it there with the
--resolveswitch:curl -sI --resolve example.com:443:198.51.100.20 https://example.com/ | head -3 HTTP/2 200 server: nginx content-type: text/html; charset=UTF-8 - Measure the new server's ping and TTFB from several networks — a fixed line, mobile internet and a different operator — and compare them with the previous figures.
- Change the record, then keep the old server running for at least a week so that long-lived caches move over too; at the end, set the TTL back to its normal value.
The full list of tasks before and after the move is in our guide on how to migrate a website to a new host.
Reducing latency with Mehran Host services
Latency is a tax your users pay for distance, and changing the geography brings it close to zero. Here is what Mehran Host offers for exactly this job:
- Cloud servers in an Iranian data center: KVM machines with NVMe disks and hourly billing — made for precisely this decision: create a server, measure ping and TTFB, compare them with your current figures and, if you are not convinced, delete it. And note: powering the machine off doesn't stop the meter, because its disk and RAM stay reserved; only deleting it completely brings the cost to zero.
- Servers and hosting abroad in Hetzner data centers — paid in Toman, Iran's currency, with no international card needed. Shared hosting is offered on cPanel and DirectAdmin.
- A CDN with edge nodes in Iran and Europe, switched on with one toggle next to any A record in the DNS panel; on a domain whose DNS is managed here, the first 1 TB of its traffic is free, and the origin can stay anywhere in the world.
- Managed DNS with A, AAAA, CNAME, MX, TXT, NS, SRV and CAA records and a minimum TTL of sixty seconds — the very tool you need for step one of the migration checklist.
A practical step you can take today: measure your current server with ping and curl, create a test server in an Iranian data center and repeat the same two commands. To get started, sign up with Mehran Host.
Frequently asked questions
How do I reduce my website's ping and latency?
The most effective step is to move the server closer to your main audience; propagation delay is a function of physical distance, and no software setting can break it. After that, cut the number of round trips: remove redirect chains, enable TLS 1.3 and session resumption, keep connections alive with keep-alive and HTTP/2, and serve fonts and scripts from your own server.
What is a good ping for a website with an audience in Iran?
A good ping for an audience in Iran is under 20 ms with little jitter, measured from a fixed line inside the country to a server in an Iranian data center; up to about 30 ms is still acceptable. On mobile internet, 30 to 70 ms is normal, because part of the latency is created in the radio network, while a server in Europe is usually 80 to 150 ms away. More important than the average are a stable number and zero packet loss.
What is the difference between ping and TTFB?
Ping is the time of one packet's round trip at the network layer, measured with the ICMP protocol; TTFB is the time from the start of a request until the first byte of the HTTP response arrives, and besides the network it includes the DNS lookup, the TCP and TLS handshakes, redirects and the application's processing time. That is why TTFB is always several times the ping. If ping is low but TTFB is high, the problem is in the code or the database, not the network path.
Does a CDN reduce a website's ping?
Only partly: a CDN reduces the latency of static files such as images, CSS and JavaScript, because it delivers them from an edge node close to the user. But dynamic pages and the first byte of HTML usually come from the origin server, and their latency depends on that server's distance. The first request for any uncached file also pays for user-to-edge plus edge-to-origin. So a CDN complements the right choice of data center; it doesn't replace it.
Why does my website's ping go up at night?
Your website's ping goes up at night because at peak hours more traffic competes for the same path capacity and packets queue in the buffers of intermediate equipment; as a result, average latency and jitter rise together. The effect is far stronger on paths that cross Iran's international gateway than on domestic ones. To diagnose it, run mtr once at a quiet hour and once at peak time, and see which hop the jump starts from.