How to Choose a VPS Location in Europe by Latency

You want a European VPS and you are stuck on the country: Netherlands, France, Latvia, Estonia. There is clearly a difference, but how much of one? This guide covers how to choose a VPS location the dull, reliable way: by measuring real latency to your own audience instead of guessing from a map on a hosting site. The even shorter version: for a blog, a Telegram bot, a cron job or a backup target, the country barely matters, so pick on price and convenience. Below: when latency actually matters, how to measure it yourself in a few minutes, and why a server "in the next country" sometimes answers slower than one 1,500 km away.

TL;DR. Latency (RTT, round-trip time) is physics plus routing. Physics: light in fiber covers about 200 km per millisecond one way, so a round trip picks up roughly 1 ms for every 100 km of path. Routing adds another 30 to 100 percent on top. The RTT that ping reports is already close to the full network contribution to waiting for a reply (request out, response back); a new connection adds TCP and TLS handshakes on top of that. Measure ping, mtr and curl -w from your users' side to the specific candidate location and decide on the numbers. Among WeaselCloud's four locations, Western and Central Europe usually lands closer to the Netherlands or France, and the Baltics or a CIS-facing audience closer to Latvia or Estonia, but treat that as a hypothesis to test, not a law. A global audience or a site behind a CDN: the origin location matters little.

What RTT is, and why it is not the whole delay

Latency is the time a packet needs to travel from point A to point B. In practice you almost always see RTT (round-trip time): request goes to the server, reply comes back. That is the number ping reports.

Half the RTT is sometimes used as a very rough estimate of one-way delay: if ping is 40 ms and the route is symmetric, propagation one way is around 20 ms. But a user does not press a button just to get a packet to the server; they need the answer back. For an already-established connection, the chain "client to server to processing to client" over the network is already close to a full RTT, not half of it. And if the connection still has to be set up, TCP and TLS handshakes add several more RTTs. HTTP/3, connection reuse and TLS 1.3 cut those handshakes down, but the principle holds: the network contribution to a response is on the order of one full RTT, plus the server's processing time.

The practical takeaway is simple. An RTT of 40 ms is comfortable for interactive work; a person barely notices. An RTT of 250 ms already reads as a sluggish interface. Judge by the full ping figure, not half of it.

Latency has two parts.

• Physics. Light in fiber glass travels about a third slower than in vacuum, roughly 200,000 km/s. That is about 200 km per millisecond one way, so a round trip gains around 1 ms for every 100 km of distance. The farther the server, the bigger this number, and nothing changes it.
• Routing. The path traffic actually takes through intermediate routers. Cables rarely run in a straight line, every hop adds a little delay, and sometimes traffic detours through another city. Together this multiplies the physical floor by roughly 1.3 to 2.

Hence a rough rule: take the map distance to your audience, divide by 100, and you have the lower bound of RTT in milliseconds. Reality will sit 1.5 to 2 times higher. Nobody beats the physical floor, not with tuning and not with a "premium" plan.

When location matters, and when it barely does

Latency only bites where there are many small request-response exchanges in real time, with a live person or a hard timeout waiting on each one. Everything else shrugs off a few tens of milliseconds.

What that looks like in practice: an interactive dashboard where every click is a round trip to the server feels instant at 20 ms RTT and draggy at 200 ms. An online game with position sync is already uncomfortable at 150 ms. A static blog behind a CDN is trickier: if the HTML and assets really are cached at the edge near the visitor, the reader gets the page from there almost every time, and where your VPS origin sits matters little - Amsterdam versus Riga is usually a small difference. But HTML is often not cached, cache misses happen, and API calls go straight to the origin, in which case the origin's location matters again. A backup to remote storage: for large volumes, throughput usually matters more than an extra few tens of milliseconds of RTT - though on a fast single-stream TCP link, high latency can also cap the rate through TCP's congestion window. A Telegram bot on long polling (the bot polls for updates and holds the connection open) absorbs even 300 ms and generally stays perfectly usable, though a few extra Telegram-to-bot round trips can add up to a noticeable fraction of a second.

On SEO specifically: a low TTFB (time to first byte) speeds up page load and feeds into user-facing metrics, including LCP. Google uses Core Web Vitals and other page-experience signals, but a couple of tens of milliseconds of RTT from the server's country gives no noticeable ranking advantage on its own. An unloaded server that returns the page quickly matters far more. If your audience is global, a CDN buys you more than a lucky choice of country.

How to measure latency from your audience's side

The key point: measure from your users toward the candidate server, not from your own laptop or from the VPS back to you. If your readers are mostly in Poland and you are in Tbilisi, your personal ping tells you nothing useful. Options: rent a candidate server for a month and test it, ask a user or a friend in the target region to run the commands, or use browser-based tools and RIPE Atlas (covered at the end of this section).

1. ping gives you the basic RTT and packet loss. Send 20 packets so you see the spread, not one random value.

ping -c 20 example.com

• -c 20 sets the packet count; on Windows use ping -n 20 example.com instead.

What you should see on the last line: rtt min/avg/max/mdev = 12.3/14.1/22.7/2.1 ms. Read avg (mean) and mdev (mean deviation of the RTT; people call it jitter colloquially, though strictly it is not the same thing) - the lower mdev is, the steadier the link. The line 0% packet loss means no packets were dropped. Loss in ping is a reason to look at the route more closely with mtr, but it is not proof of a problem with real traffic: many networks and servers rate-limit or filter ICMP separately, and the site may work fine over TCP on port 443.

2. mtr shows the whole path hop by hop and the loss at each hop. It may not be installed; the package is mtr-tiny.

sudo apt install mtr-tiny
mtr -rw -c 100 example.com

• -r prints a report and exits instead of running the interactive view;
• -w uses the wide format and does not truncate hostnames;
• -c 100 runs 100 cycles so the statistics mean something.

How to read it: if the Avg column jumps at one hop and the raised latency stays high on every hop after it, all the way to the destination, the extra delay probably appears on that segment. "Bottleneck" is a cautious word here: intermediate routers answer diagnostic packets differently, and with different priority, than they forward real traffic, so a single RTT spike on a middle hop on its own tells you little. Loss (Loss%) on the final hop is a real problem; loss on a middle hop with none on the final hop just means that router deprioritizes diagnostic replies, so ignore it. Hostnames often encode city and airport codes (fra, ams, waw), which is how you spot a detour. For a web server, a probe over TCP to port 443 is often more relevant than the default ICMP:

sudo mtr -T -P 443 -rw -c 100 example.com

3. curl -w measures TTFB: how long a browser actually waits for the first byte of the page. That is latency plus connection setup plus server work, which is what the user feels.

curl -w "%{time_starttransfer}\n" -o /dev/null -s https://example.com

• -w "%{time_starttransfer}\n" prints the time to first byte in seconds, plus a newline;
• -o /dev/null throws away the response body, which you do not need;
• -s hides the progress meter.

Run it 5 to 10 times in a row and look at the range of values, not one result. Each curl invocation is a separate process with its own network connection: there is no "warm" connection reused between runs. DNS may be cached by the OS, so the first run is sometimes slightly slower than the rest - that is normal. To see where the time actually went, use the breakdown:

curl -w "dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n" -o /dev/null -s https://example.com

This shows each stage's share: dns is name resolution, tcp is the TCP connect, tls is the TLS handshake, ttfb is the wait for the first byte. ttfb minus tls is roughly one RTT plus the server generating the response.

4. Browser tools and RIPE Atlas. If you have neither a machine nor a contact in the target region, use services like KeyCDN Performance Test and similar: they hit your host from dozens of locations worldwide and report TTFB from each. RIPE Atlas is a network of thousands of probes; you can run a one-off ping or traceroute from probes near your audience (it spends credits, and you earn a free allowance by hosting a probe yourself). This is the best option when "your audience" is a specific country you cannot reach physically.

Close but slow: peering and transit

Sometimes a server is geographically near but pings worse than a farther one. The reason is how networks exchange traffic.

Peering is two networks connecting directly and exchanging traffic, usually at an internet exchange (IX) in a specific city: AMS-IX in Amsterdam, DE-CIX in Frankfurt, France-IX in Paris, RIX in Riga, TLLIX in Tallinn. Transit is paying a large network to carry your traffic to everyone else. If a provider's local peering is thin, traffic from a neighbouring city can go to an exchange in Frankfurt or Stockholm and back: hundreds of extra kilometres and an extra 20 to 40 ms for nothing. The Baltics are the classic case, where a packet from Lithuania to Latvia sometimes travels via Sweden. It also cuts the other way: the path between two "far apart" countries can be shorter than the map suggests when both are well represented at one large IX.

How to see it: the same mtr -rw -c 100 (or with -T -P 443). If the route from Warsaw to Riga shows hops with sto or fra in the name and Avg jumps there, that is your detour. The fix is either a provider present at the local exchange, or simpler: measure the candidates and trust the number, not the map.

Which VPS location to choose for your audience

If your measurements show the options are within a few milliseconds of each other, choose on price, jurisdiction and support, not latency. If the gap is tens of milliseconds and the project is interactive, you need a starting point.

The table below is not a universal map of Europe. For Central Europe the natural candidate is Germany; for Scandinavia, Stockholm or Helsinki; for Poland, Warsaw; and a user in Eastern Europe is not guaranteed a lower RTT to Riga than to Frankfurt - BGP and the peering of specific providers decide. This is a starting hypothesis for choosing among the four locations WeaselCloud offers (NL, FR, LV, EE). Make the final call by measurement.

WeaselCloud's European locations are the Netherlands, France, Latvia and Estonia. Before you order, run ping and curl -w to each of them from your audience's side (or via RIPE Atlas and a browser tool) and compare the numbers. If they are close, decide on the other criteria. Plans and any current promo code are on the plans page. If you are migrating an existing project rather than choosing a server from scratch, that is a separate topic, covered in a dedicated write-up.

FAQ

What counts as good latency for a VPS?

For interactive workloads: RTT under 30 ms is excellent, 30 to 80 ms is fine and mostly unnoticeable, 80 to 150 ms is tolerable, and above 150 ms you feel it in dashboards, games and calls. For a blog, a bot, backups and background jobs, almost any value up to 200 to 300 ms is fine.

Are ping and RTT the same thing?

ping is the utility that measures RTT (round-trip time), how long a packet takes to reach a host and come back. When someone says "20 ms ping" they mean the RTT, the full there-and-back. Half the RTT is sometimes used as a very rough one-way estimate, but an application's response time includes the full request-and-reply exchange, plus TCP/TLS handshakes on a new connection.

Does VPS location affect search rankings?

Indirectly and weakly. A low TTFB speeds up loading and feeds user-facing metrics, including LCP, and Google uses Core Web Vitals in its page-experience assessment. But a couple of tens of milliseconds of RTT from the server's country does not move rankings on its own. An unloaded server matters more, and for a global audience, a CDN.

Do I need a VPS near my users if the site is behind a CDN?

Usually not - with a caveat. If the CDN actually caches the HTML and assets the visitor needs, they get them from an edge node nearby, and the origin's location is a question of convenience and price. If the HTML is not cached, a cache miss occurs, or the page makes many API calls, those requests go straight to your origin server, and its location affects speed again.

Why does a server in a neighbouring country ping worse than a distant one?

Routing and peering. If the local provider has no direct traffic exchange at the local IX, packets go to a large hub (Frankfurt, Stockholm) and back, adding kilometres and milliseconds. You can see the detour in mtr from the intermediate hostnames.

How do I measure latency to a server I do not have yet?

Three ways: rent the smallest plan for a month and test it; ask a contact in the target region to run ping and curl -w; run a one-off measurement via RIPE Atlas from probes near your audience. Many providers also publish a test IP or file for each location.

mtr shows loss on a middle hop - is that bad?

Not necessarily. If the final hop shows no loss but a middle hop does, that almost always means the intermediate router does not answer diagnostic packets as a priority. The warning sign is loss that starts at some hop and continues to the end of the path.

Takeaways

• Latency is set by physics (about 1 ms round trip per 100 km of fiber) plus routing on top (plus 30 to 100 percent). Nobody beats the physical floor.
• The network contribution to an app's response is close to the full RTT that ping reports; a new connection adds TCP/TLS handshakes. Half the RTT is only a rough one-way estimate.
• Location is critical for interactive dashboards, games, calls, real-time APIs and trading. For a blog behind a CDN, bots, backups, cron and queues, it barely matters.
• Measure from your audience's side, not your own: ping -c 20, mtr -rw -c 100 (or -T -P 443), curl -w "%{time_starttransfer}\n" over 5 to 10 runs.
• Among WeaselCloud's four locations: Western and Central Europe usually leans to the Netherlands or France, the Baltics and a CIS-facing audience to Latvia or Estonia. That is a hypothesis to confirm by measurement, not a universal map of Europe.
• "Close but slow" is thin peering: traffic detours through a distant hub. Visible in mtr.
• The latency table is order of magnitude. Before you buy, ping the candidate location yourself.