Where a server physically sits decides several things at once, and the instinctive choices: near me, or near the customers, are sometimes both wrong.
Latency, and where it actually matters
Distance costs time and no amount of hardware fixes it. A server on another continent adds a delay to every request, and that delay is repeated for every element the page needs.
But two qualifications change the picture.
A content delivery network removes most of it for static files by serving them from somewhere near the visitor, leaving only what the application actually generates. For that, see choosing and setting up a CDN.
And the latency that hurts most is not to visitors at all: it is between the application and its database. A page making thirty queries pays the round trip thirty times. Never separate an application from its database across a long link. That single mistake costs more than any location choice.
Measure rather than assume
ping -c 20 server.example.com mtr -r -c 20 server.example.com
Map distance is not network distance. A well-connected facility further away is frequently faster than a poorly connected nearer one, because the traffic takes a better path.
Most providers offer a test address per location. Run it from where your visitors actually are (not only from your own office) before deciding.
Understanding bandwidth, port speed and network limits walks through the other network figures quoted alongside location.
Jurisdiction
The data on the machine is subject to the law of the country the machine is in, and often to the law of the country the provider is incorporated in.
For most sites this is not a constraint. It becomes one when you hold regulated data, when customers ask where their data is stored, or when a contract specifies a region.
Ask the provider directly where the machine sits and where the company is registered. Those can differ, and both matter. What your hosting provider can and cannot see explains the access side of the same question.
Support hours and hands on site
This is the consideration people forget and regret.
A dedicated server has hardware. A failed disk, a machine that will not power on, a cable that needs reseating, all of these need somebody physically present.
If the facility's staffed hours are your night, a hardware failure at your busiest time waits. Ask what the on-site coverage is and what the replacement time for a failed disk actually is, in hours.
Remote management reduces how often that matters, because a great deal can be done without hands. Using IPMI and out-of-band management goes into what it can and cannot do.
What does not decide it
Being close to you. You administer the machine over the network, and a few milliseconds of extra latency on an SSH session is imperceptible.
Marketing descriptions of the facility. Tier ratings and certifications are real and are largely comparable between reputable providers. They rarely distinguish the actual choice in front of you.
If visitors are genuinely spread out
Pick the location closest to the largest share, put a CDN in front, and stop there.
Running servers in several regions means synchronising data between them, which is a substantially harder problem than the latency it solves. It is the right answer for a small number of applications and the wrong answer for almost every website. For what it involves, see managing multiple servers consistently.
Moving later
Changing location later means migrating the server, which is a planned operation instead of a setting.
That is a reason to think about it now and not a reason to agonise: the migration is a day's work with a DNS cutover, not a rebuild. For the sequence, see planning a DNS cutover.
Measure from where your visitors actually are
Choosing by intuition produces a decision based on where you sit rather than where the audience does.
awk '{print $1}' ~/logs/example.com | sort -u | head -50 > /tmp/ips.txt
curl -s "https://ipinfo.io/$(head -1 /tmp/ips.txt)" 2>/dev/null | grep -E 'country|region'
for h in test-eu.example test-us.example; do
printf '%-20s %s\n' "$h" "$(curl -s -o /dev/null -w '%{time_connect}' "https://$h/")"
done
The log tells you where requests come from. Testing connection times from those regions to candidate locations turns the choice into a comparison rather than a guess.
The figure that matters is the connection time rather than the total, since that is the part distance controls. Everything after it is the server's speed, which the location does not change.
Latency matters most for the things that repeat
A single page load absorbs distance well. What suffers is anything requiring several round trips.
A secure connection needs a handshake before any content moves. A page loading twenty separate files pays the distance cost repeatedly unless they are reused on one connection. And anything interactive, where the visitor waits for a response before continuing, feels the delay directly.
curl -s -o /dev/null -w 'connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n' https://example.com/
The gap between the first two figures is the handshake, and it is roughly proportional to distance. On a site where that gap is large, moving closer helps more than any amount of server tuning.
What follows the data rather than the visitors
Two constraints can override the latency argument entirely, and both are worth settling before choosing.
Where personal data is legally required to stay within a region, that decides the location regardless of performance. It also affects backups, since a copy stored elsewhere is the data leaving that region.
And where the site depends on a service hosted somewhere specific, such as a database or an API, the round trip between them happens on every request. Placing the server far from the thing it talks to constantly is worse than placing it far from visitors, because visitors wait once and the application waits repeatedly.