Does It Matter Where Your Server Is?

Update, 19 September 2026: every Maxinodes plan now includes mailboxes on your own domain. This article has been updated to match. We have also corrected how our off-site backups are encrypted, and the PHP versions and firewall we list.

• 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. At the time of that test our HTML was marked private and uncacheable, so every request made the full trip back regardless, and starting that trip from Tallinn rather than Amsterdam simply added distance.

None of that is a criticism of the CDN, which was doing exactly what it had been 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. We've since taken that decision for these marketing pages, which is why the table above is a snapshot of one afternoon rather than a standing promise. The sites we host for customers are a different case entirely: they sit behind no edge network at all, and go straight from our servers in the Netherlands to the visitor.

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 want is for the data itself — the site, the database, the mailboxes, the files your customers uploaded — to sit in the EU, on hardware belonging to a company you can name. 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.

You'll usually see this sold as "no US CLOUD Act exposure", and that phrase deserves more care than it normally gets, because as a blanket claim nobody in this industry can honestly make it. The Act reaches a US-incorporated company for data in its possession or control, and almost every hosting stack has a US company in it somewhere: an edge network, a helpdesk, a licence server, a backup vendor. Ours does too. What separates providers isn't whether such a company exists in the chain — it's what each one would actually have to hand over.

On that, we can be specific. Your site, your database, your files and your mailboxes sit on our own machines in the Netherlands, administered by us and nobody else, and your visitors' requests go straight there: no edge network terminates the connection on the way. Our off-site backups, mail included, go to a US-incorporated provider's Amsterdam region, where that provider encrypts them at rest (AES-256), so that provider holds a copy too. Support, payments and outgoing mail are the honest exceptions: our helpdesk runs on a US platform, and so do the company that takes card payments and the fraud check that runs on every order — so what you write to us, and what you enter at checkout, does leave the EEA. Mail sent from your mailboxes, and by your website, is relayed through MailChannels, a Canadian company whose relay servers are in the United States, so it leaves the EEA on its way out; the mailboxes themselves stay on our machines in the Netherlands. We name each of them, and the safeguard each does and does not offer, rather than let you assume otherwise.

That's a narrower claim than "nothing ever touches America", and it's the better one, because it's a claim about your customers' data rather than about our address book. We went through the full 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 8.2 through 8.5, switchable per site, because an old PHP version costs more speed than an ocean does.
• A web application firewall at the web server, with its WordPress rules switched on, so known attack patterns are blocked before they reach a site.
• JetBackup with real per-plan retention, off-site, encrypted, inside the EU.
• Our own nameservers, free migration on every plan, IPv6 throughout, and support with a response target set out in the SLA on Managed plans.

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.