In short. A site that answers in 80 ms locally and takes four seconds from another continent usually has a healthy server. Distance does not add delay once — it is paid again on every round trip, and a normal first page view spends four or five of them before a single byte of HTML arrives. Cutting round trips matters more than making the server faster.
The number that explains almost everything
Light travels through fibre at roughly two thirds of its speed in vacuum, about 200 000 km per second. That gives every pair of points on the planet a latency floor that no hardware, no tuning and no amount of money can go below.
Between London and Sydney the great-circle distance is about 17 000 km. One way at fibre speed is roughly 85 ms, so a round trip cannot be faster than about 170 ms. Real routes are longer than great circles and pass through switching equipment, so measured round trips on that path typically land between 250 and 300 ms.
Now the part that most explanations skip. That figure is not the delay your visitor experiences. It is the delay of one exchange, and loading a page requires several before any content appears.
Counting the round trips before the first byte
A first visit from a cold browser, to a site it has never contacted, spends its time like this:
| Step | Round trips | Can it be removed? |
|---|---|---|
| DNS resolution | 1 or more | Reduced by anycast DNS and short CNAME chains |
| TCP handshake | 1 | Removed only by reusing an existing connection |
| TLS 1.3 handshake | 1 | Reduced to 0 with session resumption |
| TLS 1.2 handshake | 2 | Removed by upgrading to TLS 1.3 |
| Request and first byte | 1 | No — this one is the transaction |
With TLS 1.3 that is four round trips. With TLS 1.2 it is five. Multiply by a realistic intercontinental round trip:
# Round-trip cost before any HTML arrives, with an instantly-responding server
# local visitor 20 ms RTT x 4 = 80 ms
# same continent 60 ms RTT x 4 = 240 ms
# intercontinental 270 ms RTT x 4 = 1080 ms
# intercontinental, TLS 1.2
# 270 ms RTT x 5 = 1350 msBoth statements your team is making are therefore true at once. The server really does respond in 80 ms. The visitor really does wait more than a second. Nobody is measuring wrong — they are measuring different things, and the difference is round trips.
This is why "the server is fast, so the site is fast" fails as an argument. Server time is one term in the sum, and on a distant connection it is often the smallest one. Optimising it while ignoring round trips is optimising the term that is already small.
Every extra origin repeats the whole ritual
The counting above covers one hostname. A page that pulls fonts from one domain, analytics from another and images from a third pays DNS, TCP and TLS again for each — in parallel where the browser can, but each chain still starts from zero.
The damage is worst when the requests are chained: the HTML must arrive before the browser learns about the stylesheet, and the stylesheet must arrive before it learns about the font it references. Each link in that chain is another full round trip at intercontinental cost.
# How many distinct origins does the page contact?
curl -sS https://example.com/ \
| grep -oE '(https?:)?//[a-z0-9.-]+' \
| sed 's|^https\?:||; s|^//||' | sort -u | head -20Cutting a third-party origin removes an entire handshake sequence for every distant visitor. That is usually a larger win than anything you can do to the server, and it costs nothing at runtime.
Measure per region before you change anything
The failure to diagnose this correctly nearly always comes from measuring in one place. Take the timing breakdown from at least two vantage points and compare the shape, not just the total:
curl -o /dev/null -s -w '
dns: %{time_namelookup}s
connect: %{time_connect}s
tls: %{time_appconnect}s
ttfb: %{time_starttransfer}s
total: %{time_total}s
' https://example.com/Then read the intervals rather than the cumulative timers:
| What grows with distance | What does not | Conclusion |
|---|---|---|
| connect and tls intervals | the gap between request and first byte | Round-trip bound — the server is fine |
| the gap between request and first byte | connect and tls | Server-side work; distance is not the issue |
| everything, proportionally | nothing | Route quality or congestion, not just distance |
| dns only | the rest | Resolution path — anycast or CNAME chain |
The first row is the common case and it is the one that misleads teams, because the server-side number looks identical from both locations. That identical number is the proof, not the puzzle: it shows the application is not what changed between the two measurements.
The speed check gives the breakdown for a page, and ping and port checks plus traceroute show the raw round trip and the path it takes. For a continuous per-region view, multi-region monitoring records response time from several places on a schedule, which is what turns "our Australian customers complain sometimes" into a comparison you can act on.
Fix 1: remove round trips before adding infrastructure
These changes cost less than a CDN contract and often deliver more on the specific problem of distance.
- TLS 1.3. One round trip instead of two on every fresh connection. At 270 ms that is 270 ms removed from every first visit.
- Session resumption. Returning visitors skip the handshake almost entirely.
- HTTP/2 or HTTP/3. One connection carries every request instead of opening several. HTTP/3 additionally survives packet loss without stalling every stream, which matters more on long paths than short ones.
- Fewer origins. Each one removed is a DNS, TCP and TLS sequence removed.
- Shorter dependency chains. Reference critical resources from the HTML rather than discovering them through a stylesheet.
- Anycast DNS. Resolution answered from a nearby node rather than a single distant authoritative server.
# Which TLS version is actually negotiated?
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>&1 \
| grep -E 'Protocol|Cipher'
# Is HTTP/2 or HTTP/3 in use?
curl -sSI --http2 https://example.com/ | head -1
curl -sSI --http3 https://example.com/ 2>/dev/null | head -1Fix 2: a CDN helps exactly as much as it caches
"Add a CDN" is the standard answer, and it is right for the right content. It is worth being precise about when it does nothing.
A CDN shortens the distance for content it can serve from the edge. For a cache hit, the visitor's round trips terminate at a nearby node and the physics improves dramatically. For a cache miss on a personalised or dynamic page, the edge still has to reach your origin — so the visitor pays the original distance plus the extra hop.
# Are you actually getting hits? Check the cache header your edge sets.
curl -sSI https://example.com/ | grep -iE '^(cf-cache-status|x-cache|age|x-served-by):'
# Compare a static asset against a dynamic page
for p in /assets/logo.svg /account/dashboard; do
printf '%-24s ' "$p"
curl -sSI "https://example.com$p" | grep -iE '^(cf-cache-status|x-cache):' || echo 'no cache header'
doneA CDN in front of a site that misses on every request has not solved a latency problem — it has added a hop to it. Before buying capacity, measure the hit ratio on the pages that are actually slow. If it is near zero, the work is to make responses cacheable, not to move them.
Where dynamic content genuinely cannot be cached, the remaining options are to move computation closer — a regional origin or edge execution — or to accept the floor and design around it, with optimistic interfaces that do not block on a round trip.
When it is not distance at all
Three patterns look like a distance problem and are not. Each has a distinguishing signal.
Route quality, not route length
If measured round trips are far above the physical floor for that distance — several times higher — the path is bad rather than long. Traceroute from the affected region and look for a hop where latency jumps and stays high. This is a transit or peering issue, and the fix is usually a provider conversation rather than a code change.
Filtering that looks like slowness
Requests that are being inspected, throttled or partially blocked present as intermittent slowness with occasional failures rather than uniform delay. The tell is variance: distance produces a consistent floor, filtering produces a wide spread with the same page sometimes fast. Region-specific reachability is worth checking directly with availability checks by region.
A single slow dependency
If one third-party call in the response path is slow from that region — a payment provider, a geo lookup, an analytics endpoint — the whole page inherits it. The signature is that the server-side interval grows while connect and TLS stay flat, which is the second row of the table above.
What good looks like
Set expectations against the floor rather than against your local experience. A page that is intercontinentally distant will not match a local one, and chasing that is chasing physics. What is achievable:
- Round trips before first byte reduced from five to three or fewer.
- Static assets served from an edge with a high hit ratio.
- Server-side interval identical from every region — proof the application is not regional.
- Measured round trip within a small multiple of the physical floor for that distance.
- Variance low; the same page from the same place should not swing by seconds.
Those five are measurable, and four of them do not require buying anything.
How to check your site right now
Run the speed check for the timing breakdown, the protocol test to confirm you are negotiating TLS 1.3 and a modern HTTP version, and the header checker to see whether cache headers indicate hits or misses. Traceroute and ping give the raw path and round trip.
Single measurements cannot see this problem properly, because it is by definition a difference between places. Monitoring from several regions records response time per location on a schedule, so a regional regression shows up as a diverging line rather than as a support ticket. For the stage-by-stage view of where server time goes, see the TTFB breakdown; for isolating a failure rather than a slowdown, the layer isolation guide.
Frequently asked questions
Why is my server fast but my site slow abroad?
Because server time is one term among several, and the others scale with distance. Four or five round trips happen before the server is even asked for content, and each one costs the full intercontinental latency.
Will a faster server help?
Only in proportion to how much of the total it represents. If the server-side interval is 80 ms out of a 1.4 second load from that region, halving it saves 40 ms. The round trips are where the seconds are.
Is a CDN always worth it?
For cacheable content, yes — it removes distance for the majority of bytes. For pages that miss on every request it adds a hop instead. Measure the hit ratio on the slow pages before deciding.
How much can I realistically improve?
The floor is fixed by distance, but the multiplier is not. Going from five round trips to three removes roughly 40 % of the pre-content delay, and serving static assets from an edge removes distance for most of the payload. What you cannot do is make a distant connection behave like a local one.
Why does it vary so much for the same user?
Consistent slowness is distance. Wide variance points at route quality, congestion or filtering. Compare measurements over time from the same location — a stable high number and a jumpy one are different problems with different owners.
Should I run servers in every region?
Only after the cheaper work is done. Removing round trips and caching what can be cached is free of operational complexity; regional origins bring data consistency, deployment and cost questions that outlast the latency problem you bought them for.
Checklist
- Calculate the physical floor for the distance before calling anything slow.
- Count round trips before first byte — that is where the seconds live.
- Measure from at least two regions and compare the shape, not the total.
- Confirm the server-side interval is identical between regions.
- Negotiate TLS 1.3 and enable session resumption.
- Reduce the number of distinct origins the page contacts.
- Check the cache hit ratio before crediting or blaming a CDN.
- Look for a latency jump at one hop before assuming distance.
- Treat high variance as a different problem from a high floor.
- Track per-region response time continuously, not by hand.
