What latency actually costs your server

Choosing where to host is usually done by price, occasionally by which datacentre the provider mentions first, and almost never by where the players are. That last one is the only input that matters, and getting it wrong is not recoverable by buying a faster machine.

Latency is distance, mostly

Network latency between two points has a floor set by physics and a ceiling set by routing. London to Frankfurt is about 15ms and no amount of money changes that. London to Sydney is about 250ms for the same reason.

What a good host buys you is the difference between the floor and what you actually get — clean peering, no congested transit, no absurd path that routes European traffic through New York. What it cannot buy you is a shorter planet.

So the hosting decision is a geography decision first and a specification decision second, and the specifications are where every comparison page spends its time.

What each band actually feels like

For a shooter, the thresholds are sharper than people expect:

• Under 30ms is invisible. Players stop noticing the network exists.
• 30 to 60ms is fine and describes most well-placed servers.
• 60 to 100ms is playable, and competitive players will complain.
• Over 100ms changes how the game is played — peeker's advantage becomes decisive, and hit registration starts producing arguments.

For a survival or building game, add roughly a hundred to each band. Minecraft at 120ms is unremarkable; Counter-Strike at 120ms is a different game.

This is why a single "best host" answer does not exist and why hardware specs are the second question rather than the first.

The mistake that looks like generosity

Hosting centrally to be fair to everyone produces a server that is mediocre for everyone. A server in Frankfurt serving a British and a Polish community gives both of them 25ms, which is genuinely fine.

A server in Frankfurt serving a British and a Brazilian community gives one of them 15ms and the other 200ms, and the Brazilian players will quietly leave. Splitting the difference by hosting in the Atlantic would give both 110ms and lose both.

When a community spans more than one region, the answer is two servers or an accepted primary region: not a compromise location. The compromise satisfies the map and nobody on it.

Where your players actually are

Guessing this is the norm and it is avoidable. Your server already knows: connection logs carry source addresses, and a rough geographic breakdown of a week of joins is an afternoon's work at most.

Do that before renewing a plan. A surprising number of servers discover their population is not where the owner is, which is the single most consequential thing you can learn about your own server and the least commonly checked: more consequential than anything on the listing itself.

What the provider's own numbers do not tell you

A datacentre location is not a routing guarantee. Two providers in the same city can deliver very different latency to the same player depending on their transit arrangements, and the cheap one is frequently the one with the worse path.

The test is a trial. Most providers bill monthly, some hourly. Put a server up, have three players in your actual population test it, and compare against what you have. That is an hour and a few pounds against a year of a bad decision, and it is the same reasoning as testing a backup before you need it rather than trusting that it works.

Home hosting and the upload problem

Latency from a home connection is usually fine. Upload bandwidth usually is not, and the asymmetry catches people: a connection advertised as fast is describing download, and a game server almost entirely uploads.

Twenty players each receiving a steady stream is an upload load a typical residential plan struggles with well before the CPU notices. That ceiling, plus carrier-grade NAT, is most of the honest case against hosting from home, and neither of them is visible when you test with two friends.

The order to decide in

Where are the players. What latency does the game need. Which providers serve that region with good routing. Then, finally, what the machine costs.

Reversing that order is how servers end up fast, cheap and empty.