The closest data center on a map isn't always the fastest. Here's how location affects page speed and how to measure candidate VPS locations before you commit.
When you order a VPS, one of the first things the checkout asks is where to put it. Most people pick the city that sounds closest and move on. That works often enough, but it fails in a few predictable ways, and fixing the choice later means building a new server and migrating everything onto it. Five minutes of testing before you order is cheaper, and you don't need anything more than ping to do it.
Light in optical fibre travels at roughly 200,000 km per second, about two thirds of its speed in a vacuum. Every request has to go out and come back, so as a rule of thumb each 100 km of cable adds about 1 ms of round trip time. Real cables don't run in straight lines, and each router along the way adds a little more, so measured latency is always higher than the straight-line distance suggests.
A single round trip is small. The problem is that loading a page takes several of them before the visitor sees anything. A new HTTPS connection needs one round trip to open the TCP connection, at least one more for the TLS handshake, and another for the browser to send its request and get the first byte of HTML back. That is three round trips before any rendering starts, and that's before DNS or any of the CSS, JavaScript and images the page pulls in afterwards.
| Round trip time to the server | Three round trips (first byte on a new connection) |
|---|---|
| 20 ms | 60 ms |
| 80 ms | 240 ms |
| 150 ms | 450 ms |
| 250 ms | 750 ms |
A faster CPU or more RAM won't recover that time. A server with twice the resources in the wrong city can still feel slower than a smaller one near your users, which is why location deserves as much thought as the plan size.
"Closest to me" is the right answer only when you are the main user. What matters is where the traffic comes from, and that depends on what the server does.
Lvato VPS plans can be deployed in 32 data centre locations. The list at checkout currently includes:
| Region | Locations |
|---|---|
| South Asia | Mumbai, Delhi NCR, Bangalore |
| East and Southeast Asia | Singapore, Tokyo, Osaka, Seoul |
| Europe | London, Manchester, Amsterdam, Frankfurt, Paris, Madrid, Milan, Stockholm, Warsaw |
| North America | New Jersey, Chicago, Dallas, Atlanta, Miami, Toronto, Silicon Valley, Los Angeles, Seattle, Honolulu, Mexico City |
| South America | São Paulo, Santiago |
| Africa | Johannesburg |
| Oceania | Sydney, Melbourne |
Pick two or three candidates near your audience from this list and test them, using the method in the next section.
None of the locations are inside Pakistan, so the choice comes down to which nearby data centre your visitors reach fastest. On a map, Mumbai and Delhi NCR are the obvious answers. In practice, the route a packet takes depends on how each Pakistani ISP connects to the rest of the internet, and traffic headed for India does not always take the short path. Some of it goes out through other countries first and comes back, which can put a geographically close data centre behind one that is much further away.
We won't quote a single "best" location here, because the answer can differ between ISPs and can change when a provider changes its routing. Test Mumbai, Delhi NCR, Singapore and one European location such as Frankfurt or London from the connections your visitors actually use. If most of your traffic comes from mobile users, test from a mobile connection too, since mobile networks often route differently from fixed broadband.
You need two things for a fair test: a real server in each candidate location, and a machine on the same kind of network as your users.
The smallest Lvato VPS plan (1 vCPU, 1GB RAM, 25GB NVMe) is enough to measure latency. Deploy one in each location you want to compare and note the IP addresses. The plan size makes no difference to the network round trip, so there is no reason to test on a larger one. VPS plans have pro-rated refunds if you cancel within the first 30 days, so you can delete the servers you don't keep.
From a Linux or macOS machine:
ping -c 20 203.0.113.10On Windows:
ping -n 20 203.0.113.10Replace the address with your test server's IP. Look at the average and the spread, not just the lowest number. A location that averages 90 ms with every reply between 88 and 95 ms is usually a better choice than one that averages 80 ms but jumps to 300 ms every few seconds, because that jitter is what users notice as random slowness.
If a nearby location comes back slower than a distant one, a route trace shows where the time goes:
mtr -rwc 50 203.0.113.10On Windows, pathping 203.0.113.10 gives similar information. A big jump in latency at one hop, especially one whose hostname points to another country, means the traffic is taking a detour. You can't fix that from the server side, so it's a reason to choose a different location.
When your audience is spread across several countries, a public tool such as check-host.net can ping your test server from probes in many countries at once. It won't match your users' exact ISPs, but it gives a reasonable picture of which candidate serves the widest area well.
If the server's main job is calling other services, measure from the test server outwards. Run this on each candidate against the APIs your workflows use:
curl -o /dev/null -s -w "connect: %{time_connect}s tls: %{time_appconnect}s total: %{time_total}s\n" https://api.example.com/Run it a few times and compare. The location with the lowest connect and TLS times to your busiest APIs is the one to keep.
A single server can only be close to one region. If your audience is split between, say, Pakistan, the UK and the US, put the server where the largest share of visitors or revenue comes from, then put a CDN such as Cloudflare in front of the site. The CDN serves cached images, scripts and stylesheets from its own nearby locations, which removes most of the round trips for repeat assets.
The CDN does not remove the distance for anything it can't cache. Logged-in pages, checkout, search, admin areas and API responses still travel to your server and back, so the server's location still matters for the parts of the site where people are most likely to give up if it's slow.
Some constraints come before speed. If a client contract or a regulation requires data to be stored in a particular country or region, that decides the location, and you then pick the best performing option inside it. The same applies if you are connecting to a partner's system that only accepts traffic from certain networks or locations.
It also helps to think a year ahead. If you plan to expand into a second market, a location that serves both reasonably well may be a better long-term choice than the fastest option for today's audience.
Moving a server to a different location generally means deploying a new one in the new location and migrating your data across, rather than flipping a setting. To keep the switch smooth, lower the TTL on your DNS records to a few minutes a day before you move. When the new server is ready, update the records, and visitors will follow within minutes instead of hours. Keep the old server running until traffic to it has stopped.
You choose the location when you create the instance, along with the operating system or a one-click marketplace app such as NexPanel, CyberPanel, cPanel or Coolify. The server is provisioned within seconds, so testing two or three candidates takes very little time.
| Plan | vCPU | RAM | NVMe storage | Bandwidth | First month |
|---|---|---|---|---|---|
| IHP-1C-1GB | 1 | 1GB | 25GB | 2TB | $7.99 |
| IHP-1C-2GB | 1 | 2GB | 50GB | 3TB | $15.00 |
| IHP-2C-4GB | 2 | 4GB | 100GB | 5TB | $30.00 |
| IHP-4C-8GB | 4 | 8GB | 180GB | 6TB | $58.99 |
Every plan includes a dedicated IP, root and VNC console access, and a dashboard for restarts, hostname and reverse DNS changes, and bandwidth usage. Larger plans up to 12 vCPU and 24GB RAM are listed on the Lvato VPS hosting page, and you can scale up to a higher tier later without changing location.
If the server is for n8n, the one-click n8n setup guide walks through ordering the VPS, pointing a domain at it and installing n8n from NexPanel.