WordPress VPS Hosting in Europe: Amsterdam, Dublin or Prishtina? Which Location Loads Fastest for Your Visitors

For a WordPress VPS in Europe, put the server in the city closest to most of your visitors: Dublin for the UK and Ireland, Amsterdam for the Benelux, Germany, France and mixed European traffic, and Prishtina for Kosovo, Albania, North Macedonia and the rest of the Balkans. Location matters more than most WordPress hosting guides admit, because a new HTTPS visit pays the distance about three times before the first byte arrives. In our lab, a cached WordPress page took 27 ms to its first byte at a London to Amsterdam distance and 222 ms at a New York to Amsterdam distance, on the same server with the same settings. A CDN closes most of that gap for cached pages, but not for carts, checkouts, logins or wp-admin.

Key facts, checked on 14 October 2026:

• Google's guidance calls a time to first byte (TTFB) of 0.8 seconds or less good and anything above 1.8 seconds poor. TTFB includes DNS, the connection, the TLS handshake and the wait for the server (web.dev).
• A full TLS 1.3 handshake costs one round trip on top of the TCP connection (RFC 8446). HTTP/3 runs on QUIC, which merges the transport and encryption handshakes "to minimize connection establishment latency" (RFC 9000).
• Cloudflare's CDN "does not cache HTML or JSON by default" (Cloudflare docs), so a CDN alone does not move your pages closer to visitors.
• WooCommerce tells site owners to exclude Cart, My Account and Checkout from every page cache (WooCommerce developer docs).
• In a Deloitte study commissioned by Google, a 0.1 second faster mobile site went with 8.4% more retail conversions (Deloitte, Milliseconds Make Millions). It is a correlation seen across retail, travel, luxury and lead generation brands, not a lab result.
• WordPress 7.1.3, released on 6 October 2026, is the current version (wordpress.org). It is the version we tested.

Why server distance multiplies on every new visit

Round-trip time (RTT) is how long a tiny packet needs to reach the server and come back. Ping shows it. A visitor in London has about 7 ms of RTT to our Amsterdam server; a visitor in New York has about 72 ms.

The trap is that a web page never costs one round trip. When a browser opens your site over HTTPS for the first time, it has to:

1. open a TCP connection (one round trip),
2. agree on encryption keys with TLS 1.3 (one more round trip),
3. send the request for the page and wait for the answer (a third round trip, plus the time your server needs to build the page).

That third step ends at the first byte. So the simple rule is: first byte on a new visit = 3 x RTT + server time. Then the browser reads the HTML, finds the CSS, scripts, fonts and images, and asks for them, which costs more round trips again. Bigger files need several round trips of their own, because a new connection starts slowly and speeds up as data flows.

Server time is the other half. On a cached page, Nginx hands over a stored copy in a few milliseconds. On an uncached page, PHP and the database build the page from scratch, which on a small server takes tens of milliseconds or more. Only the network half changes when you move the server.

What we measured in the lab

To test the rule, we built a WordPress server and put artificial distance in front of it.

The test server

The server was an Incus container on our Amsterdam lab machine with 2 vCPUs and 2 GiB of RAM, the size of our VPS Micro, running Debian 13, Nginx 1.26.3, PHP-FPM 8.4.26, MariaDB 11.8.6 and WordPress 7.1.3 with 200 sample posts. It used HTTPS with TLS 1.3 and HTTP/2 on a local test name, wp.test, and Nginx's built-in page cache (fastcgi_cache). The whole install took 25 seconds of package downloads plus a few WP-CLI commands, and the running stack used 219 MB of memory by free -m. We do not repeat the install and cache config here: our WordPress VPS stack benchmark has them line by line, and the reverse proxy and SSL guide covers real certificates.

The homepage was 126 KB of HTML, 16 KB gzipped. For the "full page" test we added 8 typical files of the default Twenty Twenty-Five theme: two script modules, jQuery, two stylesheets, a web font and two images.

Adding distance with netem

netem is a Linux traffic tool that can hold every packet back for a set time. We used it inside the container's own network namespace only, on the loopback interface, so the browser (curl) and the server talked to each other across a fake distance. A packet crosses loopback once each way, so the delay is set to half the round trip we want. Our first check used 5 ms:

# as root, inside the lab container
tc qdisc add dev lo root netem delay 5ms
ping -c3 127.0.0.1
tc qdisc del dev lo root

Ping reported an average round trip of 10.094 ms, twice the delay, as expected. For the tests we set the delay to half of each target and ran everything at 0, 7, 11, 37 and 72 ms of round trip.

Measuring first byte with curl

curl can print the timing of each phase of a request. This is the command our normal lab user ran. The --cacert option only tells curl to trust our self-signed test certificate; leave it out when you point the command at your own site with a real certificate:

# as a normal user
curl -s --compressed --cacert /etc/ssl/certs/wp.test.crt -o /dev/null \
  -w '%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' \
  https://wp.test/

The four numbers are seconds until the TCP connection was open, until TLS was done, until the first byte (TTFB), and until the last byte. For the uncached test we sent a fake login cookie, which makes Nginx skip the page cache just as it does for a logged-in user, and checked that the X-Cache header said BYPASS:

# as a normal user
curl -s --compressed --cacert /etc/ssl/certs/wp.test.crt -o /dev/null \
  -H 'Cookie: wordpress_logged_in_lab=1' \
  -w '%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' \
  https://wp.test/

On our server with no added delay it printed 0.000746 0.004770 0.078925 0.079632: 79 ms to build the page in PHP. The cached copy came back in 6 ms. Each figure below is the median of 7 runs, and the full-page figures are the median of 5.

The results

Three things jump out of our lab numbers.

First, the three round trip rule held almost to the millisecond. At 37 ms of RTT, the connection was open at 38 ms, TLS was done at 79 ms and the first byte came at 117 ms, which is 3 x 37 plus 6 ms of server work. The same pattern showed at every distance.

Second, the full page cost about 8 round trips even with all 9 files sharing one HTTP/2 connection. curl confirmed a single connection. The small files arrived right after the HTML, but the 53 to 141 KB files needed extra round trips to finish. Fetched strictly one after another, the worst case, it took about 14 round trips. That is why 72 ms of distance turned a 20 ms page into a 0.6 to 1 second page.

Third, distance hurts cached pages the most in relative terms. From 7 to 72 ms of RTT, the cached first byte grew eightfold, from 27 to 222 ms. The uncached page grew from 95 to 286 ms because PHP time stays the same wherever the visitor is.

Two honest limits. Our loopback link has none of the packet loss or small packet sizes of the real internet, so real pages over long routes do a little worse than this, not better. And curl is not a browser: real browsers also run scripts and draw the page, which takes the same time in every city.

If your WordPress visitors sit in one region, this is the strongest argument for a WordPress VPS in the right city rather than the cheapest server anywhere.

Visitor city x server city: expected first byte

We took the round trips we measured to our own servers with the public tool ping.pe on 6 October 2026 (lowest of about 10 pings per probe city, published on our Amsterdam and Prishtina pages) and applied the rule our lab confirmed: 3 x RTT plus 6 ms for a cached page, and 3 x RTT plus 75 ms for an uncached one. We have no published ping.pe test of our Dublin server, so the Dublin column uses WonderNetwork's published averages between its own servers, as shown on our Ireland page. These are calculated figures for a new HTTPS visit, not separate measurements.

Each cell shows cached / uncached first byte. The Prishtina rows reuse the same measured links in the other direction. Every cell sits well under Google's 0.8 second line on its own, so where is the problem? It is in what follows the first byte. With the 8 round trips we measured for a modest page, a visitor in Prishtina loading a site hosted in Amsterdam waits about 0.3 seconds of pure network time, against well under 0.1 seconds from a server in Prishtina. A visitor in London loading a site hosted in Prishtina pays the same penalty the other way. For a shop, that difference repeats on every page of the buying journey.

When a CDN or page cache removes the difference, and when it does not

A CDN (content delivery network) keeps copies of your files on servers in many cities, so visitors fetch them from nearby. A page cache stores the finished HTML of a WordPress page so PHP does not have to rebuild it. The two together can make a site in Amsterdam feel local in New York, but only for some requests.

Where it works

• Images, CSS, scripts and fonts. A CDN caches these by default, and they are most of the 8 round trips in our test.
• Public pages for anonymous visitors, if you tell the CDN to cache HTML as well. Most CDNs need an extra rule or plugin for that, because they skip HTML by default.
• The connection itself. The visitor's TCP and TLS round trips end at the nearest CDN server, so even uncached requests skip two long round trips. The CDN then talks to your server over a connection it keeps open.

Where it does not

• WooCommerce cart, checkout and account pages, which must never be cached, as WooCommerce's own docs say.
• Logged-in members, course students and forum users, who carry a login cookie that bypasses the cache.
• wp-admin, the block editor and every save, which is where you and your editors spend your day.
• Site search, filters with query strings and forms, which reach PHP every time.

Each of those requests still travels from the CDN to your server and back at least once, and our lab put PHP time for one uncached page at 70 to 85 ms on 2 vCPUs. Our stack benchmark found the same bottleneck: once the cache is skipped, only CPU helps. So the rule is simple. Brochure sites and blogs with a CDN can live almost anywhere in Europe. Shops, membership sites and busy editorial teams should keep the server close to the people who log in. If your pages are slow even close by, the cause is likely on the server, not the route: our guide to a slow VPS shows how to tell.

Which city and which plan: the decision table

The plan depends on how much of your traffic misses the cache, because every miss needs a PHP worker and memory. Our lab stack used 219 MB with one site.

A very small blog also fits on VPS Nano (1 vCPU, 1 GB). Bigger agencies and busy shops can go to VDS Medium or VDS Large, and any plan can be upgraded later from the client area with a short reboot. Every plan has NVMe storage, unmetered traffic and its own IPv4 and IPv6 addresses. Availability by city is on the plans page. Compare all of it on the WordPress VPS page.

When is a VPS the wrong choice? If you run one brochure site, never log in except to post, and do not want to look after a Linux server, a good shared or managed WordPress host near your audience will serve you fine. A VPS pays off once the site earns money, carries logged-in users or hosts several clients.

A word on where your data lives

Ireland and the Netherlands are EU member states, so a WordPress server in Dublin or Amsterdam keeps customer data inside the EU, under the GDPR. Kosovo is not an EU member, and the GDPR's rules on transfers outside the EU apply when an EU business keeps personal data there. For many Balkan businesses, Prishtina is the natural home for their data anyway. Whichever city you choose, our Data Processing Agreement is part of the customer agreement, with RS Computers acting as your processor.

How to check your current host in five minutes

1. Run the curl command above against your own homepage from a computer in your main market. Run it three times and keep the middle result.
2. The first number, time_connect, is roughly one round trip. If the first byte is far above 3 x RTT, the server is slow, not the route.
3. Run it again with a logged-in cookie copied from your browser, or against your cart page. That is the time your buyers really wait.
4. Ping the server and compare with the tables above. If your visitors are in Kosovo and your RTT is 40 ms, your server is probably in Western Europe.

If the move makes sense, our WordPress migration guide moves a site with WP-CLI without changing URLs, and the WordPress on a VPS guide covers a fresh install with HTTPS.

Managed WordPress if you would rather not tune it yourself

Everything above is work you can do on your own server. If you would rather hand it over, RS Computers offers managed WordPress on demand for €100 a month. It covers speed optimisation such as the page cache and PHP tuning measured above, WordPress customisation, looking after WordPress on your server, SEO and AI search optimisation, getting your site indexed by Google, Bing and other search engines, and advice on which articles to write for your company. To start, email info@rscomputers-ks.com or write to us on Telegram.

Frequently asked questions

Does server location affect WordPress speed?

Yes. A new HTTPS visit needs about three network round trips before the first byte: TCP, the TLS 1.3 handshake and the request. In our lab the same cached WordPress page reached its first byte in 27 ms at a 7 ms round trip and in 222 ms at a 72 ms round trip. A full page with 8 files took about 8 round trips.

What is a good TTFB for WordPress?

Google's web.dev guidance rates a TTFB of 0.8 seconds or less as good and above 1.8 seconds as poor. A cached WordPress page on a nearby VPS usually reaches its first byte in well under 0.1 seconds. Uncached pages such as checkout take longer, because PHP and the database build them on every request.

Is Amsterdam or Dublin better for WordPress hosting?

Pick Dublin when most visitors are in Ireland or the UK, and Amsterdam for mainland Europe or a mixed EU audience. Our ping.pe test measured 6.6 ms from Frankfurt and 9.3 ms from Paris to our Amsterdam server, while published averages put Dublin about 11 ms from London. Both keep data in the EU.

Do I still need a server near my visitors if I use a CDN?

For a blog or brochure site, a CDN with HTML caching hides most of the distance. For WooCommerce, membership sites and wp-admin, no: cart, checkout, account pages and logged-in requests skip the cache and always go back to your server, so its location still decides how fast they feel.

Which VPS plan do I need for WordPress?

At RS Computers, VPS Micro (2 vCPUs, 2 GB RAM) suits one small site, VPS Mini (4 vCPUs, 4 GB RAM) suits a WooCommerce shop or several sites, and VDS Small (4 dedicated vCPUs, 8 GB RAM) suits agencies with many sites. Our lab WordPress stack used 219 MB of memory with one site.

Where should I host WordPress for visitors in Kosovo and Albania?

In Prishtina. Our Prishtina server is 3 ms from Skopje on our own network, while the round trip from Prishtina to Amsterdam is 36.9 ms. With about 8 round trips per page, hosting in Amsterdam adds roughly 0.3 seconds of network time to each new page load for Balkan visitors without a CDN, and to every cart, checkout or login page even with one.

Can RS Computers manage my WordPress site for me?

Yes. Managed WordPress is available on demand for €100 a month on your RS Computers server. It includes speed optimisation, WordPress customisation, looking after WordPress, SEO and AI search optimisation, getting your site indexed by Google, Bing and other search engines, and advice on which articles to write. Email info@rscomputers-ks.com or message us on Telegram to start.

Put your WordPress where your buyers are

Look at your analytics, find the country where people log in and pay, and put the server there. Then add a page cache and a CDN for everyone else. RS Computers runs KVM servers for WordPress in Amsterdam, Dublin and Prishtina with the same plans in all three cities. Pick yours on the WordPress VPS hosting page, or see all VPS and VDS plans. If you are unsure which city fits your traffic, send us your visitor countries on Telegram and we will tell you what we would choose.

← All articles