Why your website is slow in other countries: latency, distance and fixes

A website is slow in other countries mainly because of latency, not bandwidth: every request travels to your server and back, and light in optical fiber covers only about 200 km per millisecond. Loading a page takes many sequential round trips (DNS, TCP, TLS, the HTML request, then CSS, JavaScript and images), so a 200 ms round trip to a distant visitor turns into seconds. The fix is to move content closer with a CDN, edge-cached HTML and anycast DNS, and to remove round trips with TLS 1.3, HTTP/3 and fewer origins.

Latency vs bandwidth: why a faster connection does not fix distance

Bandwidth is how much data a connection carries per second. Latency is how long data takes to arrive, usually measured as round-trip time (RTT): a request out and a response back. A 1 Gbps line in Sydney still waits roughly 200 ms for every round trip to a server in Virginia, because extra capacity does not make light travel faster.

Web pages are built from many small, dependent requests, and most of the time is spent waiting between them rather than transferring data. Beyond a modest connection speed, extra bandwidth typically changes page load time very little, while every millisecond of RTT is paid again on each round trip. That is why a site feels instant on the office network next to its data center and sluggish on an equally fast connection on another continent.

The speed of light in fiber sets a hard floor

Light in optical fiber travels at about 200,000 km/s, roughly two-thirds of its speed in a vacuum. A round trip covers the distance twice, so every 100 km of fiber path adds about 1 ms of RTT. Real paths are longer than the straight line: cables follow coastlines and seabeds, traffic passes through routers and exchange points, and networks do not always pick the shortest route. Typical round-trip times between our eight test regions look like this (they vary by network, route and time of day):

Seoul – Frankfurt shows how much routing matters: the cities are closer than Virginia and Tokyo, but traffic typically takes a far longer cable path, so the RTT approaches that of London – Sydney. No server tuning can beat these numbers; only moving content closer to the visitor can.

Why one page load needs many round trips

A single round trip would be tolerable. The problem is that a first visit to an HTTPS page needs a chain of them, and most steps cannot start until the previous one finishes:

Near the server the whole chain costs about a tenth of a second. On the other side of the world the same page spends well over a second just waiting, before server processing, download time or JavaScript execution. Distance multiplies every round trip you have.

TLS 1.2 vs TLS 1.3 handshakes

TLS 1.2 needs two round trips after the TCP handshake before the browser can send its request; TLS 1.3 needs one, and resumed connections can send early data with 0-RTT. HTTP/3 runs over QUIC, which merges the transport and TLS 1.3 handshakes, so a new connection is ready after one round trip instead of two or three. At 220 ms RTT, that is the difference between 220 ms and 660 ms of setup per new connection.

Redirects, slow start and subresources

• Redirects: each hop (http:// to https://, then to www) costs a full request, and a different host adds new DNS, TCP and TLS handshakes.
• TCP slow start: a new connection starts with an initial window of about 10 packets, roughly 14 KB (RFC 6928), and roughly doubles it each round trip, so a 100 KB HTML file or a large image needs several round trips on a fresh connection.
• Discovery chains: the HTML reveals CSS, the CSS reveals fonts and background images, and JavaScript triggers API calls. Each layer waits at least one more round trip, and each new third-party origin pays its own handshakes.

Other reasons your site is slow abroad

• DNS without anycast: many registrar and hosting DNS services answer from one or a few locations. When a resolver in Sydney has no cached answer, it must query your nameservers in, say, Europe. Anycast DNS answers from the nearest of many sites, while very short TTLs such as 60 seconds cause more cache misses.
• Single-region origin: without a CDN, every byte comes from one data center. Behind a CDN that does not cache HTML, which is common for CMS and e-commerce pages, every page view still makes the trip from the edge to your origin.
• Geo-routing issues: GeoDNS often picks a server from the resolver's location, not the visitor's, so corporate networks, VPNs and distant resolvers can be sent to the wrong region. Some networks also hand traffic over far from the user, so packets between neighboring countries can detour through another continent.
• Third-party scripts: tag managers, chat widgets, analytics, A/B testing and font services each add an origin with its own handshakes, and some serve from a single region. Your own server can be fast while a widget hosted on one continent slows the page everywhere else.
• Services blocked in some countries: in mainland China most Google services are blocked, so scripts and embeds from Google domains (Maps, reCAPTCHA, YouTube, often Fonts) can hang until they time out. If such a file is render-blocking, the page stays blank while it waits. Self-host critical files and load the rest asynchronously.

How to make your website fast in every country

Put a CDN in front of everything

A CDN stores copies of your files in many cities, terminates TCP and TLS near each visitor so handshakes cost a short local round trip, and keeps warm connections back to your origin. Serve images, CSS, JavaScript and fonts from it with long cache lifetimes and fingerprinted file names. Our guide to how a CDN works covers the setup.

Cache HTML at the edge

This is the step most sites skip. If anonymous visitors all see the same HTML, let the CDN cache it for a few minutes and serve a stale copy while it refreshes in the background. On Cloudflare, HTML is not cached by default; add a Cache Rule that makes it eligible for cache and respects your origin's headers.

# Response header for public, non-personalized HTML
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=600

# nginx, http block: no shared caching when a session cookie is present
map $http_cookie $html_cache {
    default    "public, max-age=0, s-maxage=300, stale-while-revalidate=600";
    ~*session  "private, no-store";
}
# server or location block that serves HTML:
add_header Cache-Control $html_cache;

Use anycast DNS with sensible TTLs

Move your zone to an anycast DNS provider; most major CDN and cloud DNS services are anycast. Use TTLs of a few minutes to an hour for records that rarely change, so resolvers worldwide keep your answers cached.

Enable TLS 1.3 and HTTP/3

TLS 1.3 saves one round trip per new connection, and HTTP/3 saves another while coping better with packet loss on long, congested paths. Most CDNs offer both as dashboard toggles. On your own nginx (1.25.1 or newer, built with HTTP/3 support):

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    ssl_protocols TLSv1.2 TLSv1.3;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Our guide to HTTP/3, QUIC and TLS 1.3 explains the details.

Remove round trips and extra origins

• Link to final URLs and collapse redirect chains to one hop at most; HSTS lets returning browsers skip the http:// redirect entirely.
• Self-host fonts and critical scripts on your own domain or CDN instead of several third-party hosts.
• Preconnect to the one to three third-party origins the page needs early, as described in web.dev's guide to early connections.

<link rel="preconnect" href="https://cdn.example.com">
<!-- fonts are fetched in CORS mode, so they need crossorigin -->
<link rel="preconnect" href="https://fonts.example.net" crossorigin>

Add regional origins for uncacheable pages

Logged-in dashboards, search results and checkout cannot be edge-cached. For these, run application servers in two or three regions near your users with database read replicas, and route visitors with latency-based DNS or a geo-steering load balancer. Simple logic, such as redirects or A/B assignment, can move to edge functions.

How to diagnose regional slowness with an 8-region test

When you run a free 8-region speed test, Global Website Speed Test loads your page in headless Chromium from Seoul, Tokyo, Singapore, Sydney, Virginia, Oregon, Frankfurt and London in parallel, and splits each first visit into DNS, TCP, TLS, server wait (our TTFB column) and the rest of the load. Read the results in this order:

1. Find the origin. The region marked "origin" has the fastest TTFB and usually sits nearest your server or cache. Its numbers are your best case.
2. Check TCP in far regions. TCP connect takes about one RTT to wherever the connection ends. Around 200 ms from Sydney for a Virginia-hosted site means nothing sits in front of your origin; a few milliseconds everywhere means a CDN terminates connections near the probe.
3. Compare the TLS and TCP segments. In the result timeline the TCP segment is the TCP handshake alone and the TLS segment is the HTTPS handshake. TLS roughly equal to TCP indicates a one-round-trip TLS 1.3 handshake; TLS around double TCP points to TLS 1.2 or extra round trips, for example from an oversized certificate chain. (In the downloadable JSON, tcp is the whole connection time and already includes tls.)
4. Compare server wait. Far-region TTFB of roughly the origin's TTFB plus one long RTT means HTML comes from the origin on every request, while low TTFB everywhere means the edge serves HTML. High TTFB even at the origin is a server problem; see our guide to reducing TTFB.
5. Scan DNS. DNS times depend on resolver caching, but consistently slow lookups in some regions suggest nameservers far from those resolvers.
6. Compare load time and repeat visits. A wide gap between TTFB and load time in far regions means subresources also travel far. If repeat visits are much faster, caching works and the remaining cost is per page view; if not, check your Cache-Control headers.

For example, a site on a single server in Frankfurt might show TCP 1 ms, TLS 2 ms and TTFB 180 ms from Frankfurt, but TCP 240 ms, TLS 240 ms and TTFB 420 ms from Seoul: three long round trips plus server time before the first byte. With a CDN and edge HTML caching, Seoul's TCP and TLS drop to a few milliseconds and TTFB to the edge's response time. That saved time comes straight off Largest Contentful Paint for visitors in Korea, as our Core Web Vitals guide explains.

Probes run on well-connected data-center networks, so real visitors add their own last-mile latency, especially on mobile, and mainland China is not one of the eight regions. The methodology page describes how each number is measured.