Does It Matter Where Your Server Is?

• What the distance actually costs
• One round trip becomes three
• The number nobody checks
• Where distance genuinely does bite
• What a CDN does, and what it doesn't
• The two myths worth retiring
• What is genuinely local: the law
• What we spent the money on instead
• So, does it matter?

It comes up in almost every conversation we have with a business outside the Netherlands. Someone in Helsinki, or Tallinn, or Vienna is comparing us to a host down the road from their office, and they ask the reasonable question: your servers are in Amsterdam, mine would be in Finland, doesn't that make my site slower?

It's a fair thing to worry about, and most hosting companies answer it with a shrug and the word "CDN". We'd rather answer it with numbers, so we went and measured it. What follows is what we actually found, including one result that didn't flatter us.

What the distance actually costs#

Start with the physical part, because that's the bit nobody can argue with. Data moves through fibre at roughly two thirds the speed of light, and Helsinki is about 1,500 km from Amsterdam, so there is a floor under how fast any of this can be.

We measured from several independent probes sitting on different Finnish networks in Helsinki, pinging our server in the Netherlands. The clean results clustered tightly:

A traceroute out of our rack confirms why it's so consistent: ten hops, out through Worldstream's network in the Netherlands, onto a European backbone, into Finland. No detours, no congestion.

So there it is. Being in the Netherlands instead of Finland costs a visitor in Helsinki about 27 milliseconds per round trip. That number is real, we're not going to pretend otherwise, and any host who tells you distance is free is hoping you won't check.

One round trip becomes three#

Twenty-seven milliseconds sounds trivial, and on its own it is. The catch is that opening a fresh HTTPS connection doesn't take one round trip, it takes about three: one to set up the TCP connection, one or two more for the TLS handshake, and one for the request itself before the first byte comes back.

Here's the same page fetch broken down, measured from Helsinki:

So the honest figure isn't 27 milliseconds, it's closer to 80. Distance gets charged three times before the page starts painting.

Now put 80 milliseconds somewhere useful. Google's threshold for a good Largest Contentful Paint is 2.5 seconds. A typical small-business site lands somewhere between 1.5 and 3 seconds. Against that, 80 ms is about three percent. It is a real cost, and it is also comfortably the smallest line item on the bill.

The number nobody checks#

Here's the part that changed how we think about this question.

While measuring Finnish hosts for comparison, we hit the same provider twice. Their main site answered in 28 ms. Their apex domain, which does nothing but issue a redirect to the www version, took between 572 and 780 ms to produce that redirect.

Same company. Same building. Same hardware. Same city as the visitor. A twenty-five fold difference, caused entirely by what the server was doing rather than where it was sitting.

That gap is roughly twenty-five times larger than the entire distance from Finland to the Netherlands. And it is the gap almost nobody measures, because "where are your servers" is an easy question to ask and "what happens between the request arriving and the first byte leaving" is not.

Distance is fixed, small, and knowable. Configuration is variable, large, and usually the actual problem. If your site takes two seconds to respond, moving it 1,500 km closer gets you to 1.92 seconds, and you'll never notice. Turning on a page cache gets you to 0.2 seconds, and everyone will.

We wrote about where those seconds hide in why your website feels slow, and none of the top causes have anything to do with geography.

Where distance genuinely does bite#

We're not going to claim it never matters. There are three cases where it does.

Pages that can't be cached. A cached page is served from memory in a millisecond or two, and the round trip is nearly all you pay. A logged-in page is different: a WooCommerce cart, a checkout, the WordPress admin. Every one of those goes back to the origin, so every one of them pays the full distance. If you spend your day inside wp-admin, you will feel the difference between a server in your city and a server abroad. Your visitors mostly won't. You will.

Chatty front ends. If a page fires a dozen API calls one after another, each waiting on the last, you multiply the round trip by twelve. That turns 30 ms into 360 ms. The fix is to stop making twelve sequential calls, but it's worth knowing the pattern exists.

Audiences much further away. Everything above is about Europe. If half your traffic is in Singapore or São Paulo, no European origin is close to them and you should be having a different conversation, most likely about a CDN.

What a CDN does, and what it doesn't#

Which brings us to the answer we said we wouldn't give you.

The usual pitch is that a CDN erases distance: put Cloudflare in front, your visitors hit a nearby edge, everyone gets local speed. It's half true, and the half that isn't gets left out.

A CDN serves cached content from the edge, and for that it works beautifully. Images, CSS, JavaScript, fonts: all of it can sit in Helsinki or Tallinn and arrive in a couple of milliseconds no matter where your origin is.

Uncached content is another story. When the edge doesn't have the page, it has to fetch it from your origin, and now the request travels visitor to edge to origin and back. If that edge-to-origin connection isn't already warm, and on a low-traffic site it frequently isn't, you've added a handshake instead of removing one.

We measured this on our own marketing site, and the result is the one we mentioned wouldn't flatter us. Same URL, same origin, same moment, different probes:

The visitor who got the nearer edge came off worse, by a factor of three. Our HTML is marked as private and uncacheable, so every request makes the full trip back regardless, and starting that trip from Tallinn rather than Amsterdam simply adds distance.

None of that is a criticism of Cloudflare, which is doing exactly what it was asked to do. It's a caution about the mental model. A CDN is a cache, and a cache only helps with what it's allowed to keep. Put one in front of a fully dynamic site and you may move backwards.

So the honest advice: use a CDN for your static assets, where it genuinely does deliver local speed. If you want your HTML to come from the edge too, you have to explicitly make it cacheable, and that is a real decision with real trade-offs, not a checkbox.

The two myths worth retiring#

Server location is not an SEO ranking factor. This one has outlived its usefulness by about a decade. Google works out who your site is for from your domain, your hreflang tags, your language, your content, and your Search Console settings. Server IP is a weak hint at best and CDNs made it meaningless anyway. A .fi domain on a Dutch server ranks in Finland exactly as it should.

"Local" hosting is often not local. Before you pay a premium for a server in your own country, check where it actually is. A large share of national hosting brands are resellers on hardware in Germany or the Netherlands with a local name on the invoice. Run a traceroute, or look up where the IP behind the domain terminates. Sometimes the local host and the foreign host are literally in the same building.

What is genuinely local: the law#

There is one sense in which location matters enormously, and it isn't speed.

If you're an EU business handling EU customer data, what you need is for that data to stay under EU jurisdiction, with no third-country transfer to document and no US CLOUD Act exposure to explain to anyone. The Netherlands is in the EU. So is Finland. From a GDPR standpoint they are the same answer, and both are a very different answer from a cheap server in Virginia.

Our servers are in Amsterdam, our backups go off-site to a separate provider inside the EU, and they're encrypted before they leave our building, so the backup provider holds ciphertext and nothing else. We went through the reasoning in what GDPR-compliant hosting actually means.

That is the part of "where is your server" worth caring about, and on that one the answer is genuinely local.

What we spent the money on instead#

We can't buy back those 27 milliseconds. Nobody can. So the useful question is what we did with the budget that a "local" premium would otherwise have absorbed.

We run our own hardware. Not a slice of somebody's public cloud, but a dedicated Dell machine with a 24-core AMD EPYC, 128 GB of memory and enterprise Micron SSDs, which we looked after ourselves rather than renting by the hour. That means we know what else is running on it, which is not something you can say about a cheap cloud instance.

On top of that, the parts that actually move more than 80 milliseconds:

• LiteSpeed Enterprise with LSCache, which on WordPress serves a cached page in about a millisecond. That single feature is worth roughly ten times the distance from here to Helsinki.
• CloudLinux with per-account resource limits, so the busy site next door cannot eat your CPU. On oversold shared hosting this is the thing that actually ruins your afternoon, and no amount of proximity fixes it.
• PHP 5.6 through 8.5, switchable per site, because an old PHP version costs more speed than an ocean does.
• ModSecurity with the full OWASP core rule set, 979 rules, enforced at the web server.
• JetBackup with real per-plan retention, off-site, encrypted, inside the EU.
• Our own nameservers, free migration on every plan, IPv6 throughout, and support that answers every day of the week within twelve hours.

So, does it matter?#

Being 1,500 km away costs a Finnish visitor about 80 milliseconds on a cold page load. That is the true number, we measured it, and we'd rather you had it than a marketing claim.

Everything else on the list is bigger. A missing page cache costs seconds. An oversold neighbour costs seconds. Four megabytes of unresized images cost seconds. Old PHP costs tenths of a second. Server location costs hundredths.

Pick your host on what they run and how they run it. Then check they're in the EU, because that part really is about the map.

If you want to know what your site currently does from where your customers actually are, measure it yourself. It's free, it takes about fifteen seconds, it needs no sign-up, and it runs on the same probe network every number in this post came from. Then send us the result and we'll tell you what we'd fix first. You don't have to be a customer to ask.