Choosing a VPS region: latency from US and EU cities, measured

Most advice on picking a server region stops at "choose one close to your users". Close is a number, though, and it decides whether the region question matters for your app at all. So we measured it: on 2 November 2026 we pinged 17 cities in North America and Europe from our own US Central and Germany servers, then added two weeks of hourly city-pair data for the places we don't sit in.

Short version: from US Central, every North American city we tested was within 52 ms; from Germany, every European city was within 31 ms. Crossing the Atlantic costs about 94 to 115 ms from US Central to Europe, and 88 to 163 ms from Germany to North America. A first HTTPS request across the Atlantic took 361 ms in our test. If nearly all your users are on one continent, take the middle of that continent. If they are on both, the tables further down show what each location costs whom.

How we measured

From each server we sent 60 ICMP pings, 0.2 seconds apart, to Vultr's public ping hosts in 17 cities, in 4 rounds about 20 minutes apart between 00:55 and 02:00 UTC. The numbers below are the median of each round's average round-trip time. Ping targets sit in data centres, so these are server-to-server times: a real visitor's home or mobile connection comes on top.

For pairs we can't ping from, we used WonderNetwork's public ping history: 336 hourly runs per pair from 18 October to 2 November 2026. Our four rounds cover about an hour; theirs show how a route behaves over two weeks, including bad hours. Mixing two sources means small differences between tables aren't meaningful; differences of tens of milliseconds are.

From US Central and Germany to 17 cities

US Central works as a single location for North America: Chicago is 7 ms away, New Jersey 22, Los Angeles 45 and San Jose 52. Germany does the same for Europe, with Frankfurt at 9 ms, London at 15 and Stockholm at 31.

Two things in the raw data are worth saying. Rounds from US Central were very steady, with a spread inside each round (ping's mdev) of about 0.1 ms; from Germany it was mostly 1 to 7 ms, and about 11 ms on the Chicago route. And in the first round from Germany the Warsaw target lost 50% of its packets with a 395 ms average, then came back to about 26 ms for the other three rounds. Packet loss otherwise stayed at 3.3% or less in any round. One bad round on one route is normal internet weather, which is why we report medians and why one ping test on one afternoon proves little.

US to Europe, city by city

Median of the hourly averages, with the worst hourly average in those two weeks in brackets:

The East Coast is the shortcut: New York to London is 70 ms, against 125 from Los Angeles. Medians hide route trouble, though. Dallas to Frankfurt has a median of 129 ms, but at least 5% of its hours averaged 210 ms or more.

Inside the US and inside Europe

The coast-to-coast figure explains why the middle wins. A New York server is 66 ms from Los Angeles; a US Central server was at most 52 ms from anywhere we tested on the continent. Inside Europe, no median in this table passes 33 ms.

Why these numbers can't be tuned away

Light in optical fibre covers about 200 km per millisecond (the usual rule of thumb), so 1,000 km of straight path can't round-trip in less than about 10 ms. New York to London is about 5,570 km in a straight line: a floor of about 56 ms, against 70 measured. New York to Frankfurt, about 6,200 km: floor 62 ms, measured 86. Short routes run further over the floor, since cables don't run straight: London to Frankfurt is about 640 km, floor 6 ms, measured 17. No plan, CPU or tuning option changes this. Only moving the server, or caching content near the visitor, does.

What the milliseconds cost you

A ping is one round trip; real work takes several. We timed fetching a small file over HTTPS with curl, 12 samples per line, each on a new connection:

A typical cross-Atlantic request split as: TCP connected at 110 ms, TLS finished at 225 ms, first byte at 340 ms. That is three round trips: TCP, the one-round-trip TLS 1.3 handshake, then the request itself. The same-machine lines show what's left without distance: the TLS work and the server's own time. The rule that follows: first response on a new connection = about 3 x ping + server time. Requests on an open connection cost one round trip.

The last column is the one that hurts, and it is mostly self-inflicted. A page that makes 20 database queries one after another, with the database in another region, waits 20 round trips before it sends anything: 1.9 seconds at 94 ms. Keep your app and its database in the same region, whatever else you decide. That matters more than which region you choose. The same sum is why far-away single-page apps feel slow: batch the API calls, or put more into each response.

So which region?

Worst ping for each server location, using the tables above. US Central and Germany are our own figures across 17 cities; New York and London are WonderNetwork medians for the pairs listed, so they cover fewer cities:

Before moving anything, check where your users really are (your analytics will say), then test from there. A few milliseconds of difference between two regions won't show on a normal page; 100 ms repeated across 20 calls will.

Test it yourself

Run them at a few different times of day and from the place your users are, not from your server. If tcp is low and first byte is high, distance isn't your problem: the app is.

Where this lands on tport.cloud

Our small sizes run in Germany, US Central and India, and bigger servers in 9 regions including US East, US West and the UK; every order lets you choose. The $1 server (0.5 vCPU, 512 MB, free for 30 days) is an easy way to run the commands above from a real region before you commit. For sizing the box once you've picked the place, see how much RAM a small web app really needs, and for what it costs next to a Droplet, the price comparison.

Sources

Our own measurements, 2 November 2026 (ICMP ping and curl from our US Central and Germany servers; ping targets are Vultr's public hosts such as nj-us-ping.vultr.com and fra-de-ping.vultr.com). City pairs: WonderNetwork ping history, 18 October to 2 November 2026, read 2 November. Fibre speed: NANOG thread on propagation delay. TLS 1.3 handshake: RFC 8446. Straight-line distances are our own great-circle sums, rounded. tport.cloud regions and prices from tport.cloud/pricing, 2 November 2026.