Does the distance to your visitors actually matter?

Does the distance to your visitors actually matter?

Yes. Distance sets a hard floor for latency, so putting your origin server far from your visitors adds pauses they can feel. A single round trip between the UK and US is often around 70 to 80 milliseconds. Web pages need several round trips in sequence, so that delay multiplies.

This picks up from a server you can already reach over SSH.

Before you start

• You need command line access to any Linux system you control. The examples below show AlmaLinux 9 and Ubuntu 24.04.
• None of the diagnostic commands here are destructive. Package installation may need sudo.
• Know where your audience is. If most of your traffic is from the UK, our London VPS is closer. If it is from North America, our New York VPS is closer.
• If you plan to move a live site, plan DNS carefully. Copy all records first, lower TTL in advance, and expect caches to linger. Switching nameservers or MX without replicating records can interrupt web or email until caches expire. Database writes made during a move can be lost if you do not freeze them or replicate.
• If your domain will point at Hostworld hosting, set nameservers at your registrar to: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk.
• Hostworld runs two locations: our UK site sold as London VPS on the network side, and our US site in New York.
• You manage a VPS in Virtualizor from the Hostworld client area. Orders, invoices and tickets live in WHMCS at portal.hostworld.uk.

Step 1: Get a feel for distance and round trips

Physics sets the floor. Light in fibre is around 200,000 km per second. Even a perfect London to New York path cannot beat the mid‑50 ms range for a round trip. The fastest measured production cable on that path is about 58.95 ms. Real‑world paths are usually slower, often around 70 to 80 ms. A cloud region example shows roughly 77 ms median between London and Northern Virginia.

Browsers need several round trips before you see anything. There is one for DNS if uncached. There is one for the TCP handshake. TLS 1.2 adds another. TLS 1.3 reduces that setup to one round trip and can resume in zero round trips on repeat visits. Then there is the HTTP request and first byte coming back. On top of that, a page often pulls many render‑blocking assets. HTTP/2 reduces the need for new connections by multiplexing, but it cannot change the base round trip time to your origin.

What a person feels follows some rough thresholds. Around 0.1 seconds is instant. Around 1 second does not break flow. At around 10 seconds attention wanders. A single 70 to 90 ms hop is small, but if you stack several round trips in sequence you move from instant to noticeable.

Step 2: Measure your current path from the command line

Start by measuring the round trips between where your server is and where your users are, or to a well‑located test host. You can also test from your own machine to your site to see what a visitor feels.

Ping: sample round‑trip time

This checks reachability and shows average round‑trip time in milliseconds.

• AlmaLinux 9: No install usually needed.
• Ubuntu 24.04: No install usually needed.

ping -c 5 yoursite.example

traceroute: see the path

This lists the hops between you and the destination. It helps explain why a path is slow.

• AlmaLinux 9: Install traceroute if missing, then run it.

sudo dnf install -y traceroute
traceroute yoursite.example

• Ubuntu 24.04: Install traceroute if missing, then run it.

sudo apt update
sudo apt install -y traceroute
traceroute yoursite.example

mtr: combine loss and latency in one report

This runs a short test and prints a summary of loss and latency per hop.

• AlmaLinux 9: Install mtr if missing, then run a report.

sudo dnf install -y mtr
mtr --report --report-cycles 50 yoursite.example

• Ubuntu 24.04: Install mtr if missing, then run a report.

sudo apt update
sudo apt install -y mtr-tiny
mtr --report --report-cycles 50 yoursite.example

curl timings: isolate connection cost from TTFB

This fetches a URL but discards the body. It prints three timings: TCP connect time, TLS handshake time, and time to first byte. This tells you how much time is setup versus server processing.

• AlmaLinux 9 and Ubuntu 24.04: curl is usually present. If not, install it with your package manager.

curl -s -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://yoursite.example/

On a transatlantic path with TLS 1.3, a rough budget is 1 round trip for the TLS handshake plus 1 round trip for the HTTP request to first byte. At around 80 ms round trip, that is about 160 ms of TTFB before your server does any work. If you are on TLS 1.2, add another round trip. An uncached DNS lookup can add more before any of this.

Step 3: Reduce the number of round trips your pages need

Every sequential round trip across an ocean adds a pause. Cut how many you need to make a page useful.

• Use TLS 1.3. It reduces the handshake to one round trip and supports resumption. Your web server or proxy controls this. After enabling, check the effect with the curl timing above. The tls number should fall.
• Enable HTTP/2 or HTTP/3. HTTP/2 multiplexes many requests over one connection. HTTP/3 moves to QUIC and further reduces setup on high round trip time paths. Neither removes the base latency to your origin, but both reduce extra handshakes.
• Consolidate third‑party origins. Each extra origin can add DNS, TCP and TLS setup. Only include third‑party scripts and resources you need. If you must use them, consider preconnect or DNS prefetch so setup starts sooner.
• Optimise critical path. Make the first HTML byte arrive quickly, then minimise render‑blocking CSS and JavaScript so the browser shows content without waiting on many serial requests.

Step 4: Decide where your origin should live

Pick your origin region by where your visitors are and by how dynamic your site is.

• Dynamic HTML and APIs. Checkouts, dashboards, search, WordPress admin and any page that renders per request are latency‑sensitive. Hosting near the bulk of visitors cuts time to first byte they feel. A UK user hitting a US origin pays something like 70 to 80 ms for each round trip. You can easily stack 2 or 3 in sequence for the initial render. Moving that origin to the UK can remove around 150 ms or more from cold TTFB.
• Static‑heavy sites. If you serve images, CSS, JavaScript and downloads and you cache them on a CDN, the origin’s country matters much less. Cache hits come from an edge close to the visitor. Only cache misses pay the origin’s round trip while the edge fills.

Concrete example with TLS 1.3: at around 80 ms round trip between the UK and US, budget 1 round trip for the TLS handshake and 1 round trip to first byte. That is roughly 160 ms before your origin has done any work, and before DNS if it was uncached. TLS 1.2 would typically add another round trip. Over many page views that adds up.

Do not confuse bandwidth with latency. A bigger pipe does not shorten a round trip. You need enough bandwidth to carry what you send, but the distance still sets the floor for how fast each back‑and‑forth can happen.

Step 5: Put a CDN in front of static content

A CDN moves cached copies of your static files close to visitors. When the cache hits, the browser talks to a nearby edge and your origin geography does not matter for those assets. When the cache misses, the edge fetches from your origin once then serves the next request locally. This often removes the “wrong country” penalty for images, CSS, JavaScript and downloads.

• Catalogue what is static and safe to cache. Do not cache user‑specific HTML or APIs unless you know how to vary and purge correctly.
• Set long cache lifetimes on static assets and use versioned filenames so you can deploy safely.
• Measure again after enabling. A drop in time to first byte for static files and fewer origin hits are good signs.
• Do not benchmark only the CDN edge and conclude distance never matters. Dynamic HTML and APIs still pay the origin round trip on each request.

Step 6: If you need to change region with Hostworld, plan your cutover

If your testing says the origin should move, the cleanest approach is to bring up a second server in the other region, sync, then switch traffic.

1. Deploy the target server. Order a VPS in the UK or US in the Hostworld client area at portal.hostworld.uk which runs WHMCS. You will manage start, stop, reboot and the console in Virtualizor from the same client area once provisioned.
2. Prepare the new server. Install your stack, restore site files and databases. Test over a hosts file entry or a temporary domain so real users are not directed there yet.
3. Plan DNS. Lower TTL on the records you will change. A day before cutover, set TTL to something like 300 seconds so caches age out fast. Wait for the longer, older TTL to expire before you flip traffic.
4. Copy DNS records before switching nameservers. If you are moving to Hostworld nameservers, recreate all A/AAAA, MX, CNAME, TXT, SPF, DKIM and DMARC records first. Hostworld nameservers are: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk. Switching without copying risks web or email outages until caches expire.
5. Freeze writes for database‑backed sites. Stop changes on the old server at cutover time or run replication and perform a controlled switchover. This avoids diverging data while DNS propagates.
6. Flip traffic. Either update A and AAAA records to the new VPS IP or change nameservers at your registrar to Hostworld if that is your plan. Keep the old server online until you are sure all traffic has drained.
7. Monitor. Watch logs, errors and latency. Use the measurement commands again to confirm the improvement from the new region.

If you would like us to check your plan, please open a support ticket.

Step 7: Re‑measure and compare

After you change protocol settings, add a CDN or move region, take new measurements. Compare like with like using the same commands and targets.

• ping again to see the change in round‑trip time.
• mtr again to confirm the path and check for loss.
• curl again to see if TLS handshake time and time to first byte fell.

Keep in mind that DNS can be cached. Test with a fresh resolver, or wait for TTL to age, to get a clean view of the new path.

What next

If your audience is in the UK and you want the origin close, look at our UK location on the Linux VPS page. If you are comparing server tasks, browse our VPS guides for practical steps and context.

If you are not sure whether a CDN or a move will help most, describe your setup and tests and we will advise. Please open a support ticket.