WordPress Hosting in Amsterdam: A Netherlands VPS for Fast WordPress and WooCommerce Sites

For WordPress hosting in the Netherlands, a VPS in Amsterdam is the natural home for a site or WooCommerce shop that sells to Dutch, Belgian, German and French customers. RS Computers runs KVM VPS and VDS servers in Amsterdam, as well as in Dublin and Prishtina, and in our own ping.pe test on 6 October 2026, probes in Frankfurt, London and Paris reached the Amsterdam server in 6.6 to 9.3 ms. The data stays in the EU, where the Dutch supervisor is the Autoriteit Persoonsgegevens. Those milliseconds are the small part of shop speed, though: in our WooCommerce lab the server needed 113 ms to build a checkout page, and no page cache may ever store it. Below are our measurements, the changes that helped, and the plan we would pick for each kind of shop.

Key facts, checked on 14 October 2026:

• AMS-IX, the Amsterdam Internet Exchange, lists 903 connected networks and a traffic peak of 15.8 Tb/s (AMS-IX).
• Dutch consumers spent €35.7 billion online in 2025 in 347 million purchases; 13% went to webshops abroad (Thuiswinkel Markt Monitor by NielsenIQ, 31 March 2026).
• iDEAL is used for 71% of Dutch online purchases (Dutch Payments Association) and is moving onto Wero: all Dutch issuing banks are due to connect in October 2026, and the switch should finish by 31 December 2027 (EPI, July 2026).
• WooCommerce 11.2.1 (9 October 2026) has more than 7 million active installations and needs WordPress 7.0 or newer (wordpress.org).
• In our lab, an nginx page cache answered a product page in a median 0.6 ms. Built by PHP, the same page took 163 ms.

WordPress hosting in the Netherlands: who Amsterdam suits

Amsterdam suits a WordPress site whose visitors are in the Benelux, Germany, France or the UK, or spread over Western Europe. These are our ping.pe results from 6 October 2026, the lowest of about 10 pings per probe city with no packet loss. The list has no Dutch or Belgian city; shoppers there are closer to the server than any probe in it.

The full table is on our Netherlands VPS page. Not every site needs its own server: a brochure site with a few hundred visits a day runs fine on decent shared hosting. A VPS pays off when the site takes orders, when several client sites share one bill, or when you need your own PHP settings, Redis or a system cron. The price of that freedom is upkeep: on a VPS, you or someone you hire installs the updates and keeps an eye on the server.

Why a shop is only as fast as its uncached pages

Most WordPress speed advice comes down to the page cache: nginx or a plugin saves a finished page and replays it to the next visitor, so PHP and the database never run. For a blog that covers almost every request. For a shop it cannot, because cart, checkout and account pages differ for every shopper: WooCommerce sends Cache-Control: no-cache, must-revalidate, max-age=0, private on them, and its caching guide says to exclude them. Most hosting pages stop there and miss the bigger effect. Once a shopper adds something to the cart, a cookie called woocommerce_items_in_cart is set, and a correct cache then sends every page that shopper opens to PHP, product pages included. During a sale, much of your traffic is uncached.

The number to watch is TTFB, time to first byte: how long the browser waits before the page starts to arrive. Google's web.dev suggests aiming for 0.8 seconds or less. TTFB is network time plus server time. A shopper's first visit pays the round trip about three times (connect, agree on TLS 1.3 encryption, ask for the page), so by our arithmetic a shopper in Frankfurt spends about 20 ms on the network to reach our Amsterdam server. Our server then spent 100 to 250 ms building an uncached WooCommerce page. The city fixes the first number; the rest of this guide is about the second, and our server location guide does the network sums for other cities.

The lab: WooCommerce on a 2 vCPU Amsterdam test server

The shop got 2 vCPUs and 2 GB of RAM, the size of a VPS Micro and half a VPS Mini, inside an Incus container on a lab machine in Amsterdam. That machine (AMD EPYC 7742, 8 cores, not necessarily the processor behind your server) carried other test workloads at the same time, so read the numbers as a comparison between settings, not a promise for your server. The stack: Debian 13, nginx 1.26.3, PHP-FPM 8.4.26, MariaDB 11.8.6, WordPress 7.1.3 and WooCommerce 11.2.1 with the block theme Twenty Twenty-Five 1.5, plus WP-CLI 2.12.0, the command-line tool for WordPress.

# as root, on Debian 13
apt-get update
apt-get install -y nginx php8.4-fpm php8.4-mysql php8.4-curl php8.4-gd php8.4-intl php8.4-mbstring php8.4-xml php8.4-zip php8.4-bcmath php8.4-imagick mariadb-server curl less unzip sudo
curl -sS -o /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x /usr/local/bin/wp

The packages installed in 32 seconds. Create the database, the nginx site and WordPress as in our WooCommerce VPS guide, then add WooCommerce and its official sample products:

# as root, in /var/www/shop (WP-CLI runs as the web user www-data)
sudo -u www-data wp plugin install woocommerce --activate
sudo -u www-data wp plugin install wordpress-importer --activate
sudo -u www-data wp import wp-content/plugins/woocommerce/sample-data/sample_products.xml --authors=skip
sudo -u www-data wp post list --post_type=product --format=count

WP-CLI printed Installing WooCommerce (11.2.1), the import took 14 seconds, and the count was 18. We added 1,000 simple products with a WP-CLI loop (55 seconds), set the store to the Netherlands and euros, and enabled bank transfer. The site used 203 MB of disk and the database 9 MB. One fix comes before any tuning: WordPress runs its scheduled jobs, WP-Cron, inside visitor requests unless you move them to the system cron:

# as root, in /var/www/shop
apt-get install -y cron
sudo -u www-data wp config set DISABLE_WP_CRON true --raw
echo '* * * * * www-data cd /var/www/shop && /usr/local/bin/wp cron event run --due-now --quiet' > /etc/cron.d/wp-shop

WP-CLI answered Success: Added the constant 'DISABLE_WP_CRON'. The background queue now runs once a minute, about 5 seconds and 118 MB of memory per run, away from your shoppers.

How we measured

A second container on the same host played the shopper. It put the sample "Hoodie with Logo" (product ID 12) in a cart, asked for each page 25 times and kept the median. Then hey, a load tool in Debian (apt-get install -y hey as root), kept 10 connections busy for 15 seconds:

# as any user, on a second machine
curl -s -c cart.txt -o /dev/null "http://shop.test/?add-to-cart=12"
for i in $(seq 25); do curl -s -o /dev/null -b cart.txt -w "%{time_starttransfer}\n" http://shop.test/checkout/; done | sort -n | sed -n 13p
hey -z 15s -c 10 http://shop.test/product/hoodie-with-logo/

On our final setup the loop printed 0.123014 (a 123 ms median for the checkout), and hey reported Requests/sec: 9.7357 with [200] 151 responses. Replace shop.test with your domain.

What each change did to product, cart and checkout pages

Median TTFB in milliseconds with no page cache, then requests per second with 10 connections; each value is the average of two rounds. "Store API" is the cart request that WooCommerce's cart and checkout blocks send from the browser. Each row keeps the changes above it.

OPcache keeps PHP's compiled code in memory; without it, every request compiles WordPress and WooCommerce again, and pages were 2.8 to 7.9 times slower. Debian 13 turns it on by default, but check any server you take over. After that, the usual tips changed little: tuned OPcache plus Redis took 4 to 8% off each page, close to the noise between rounds, and throughput stayed put. The container's CPU counter shows why. Under load both vCPUs were fully busy, and an uncached product page cost about 0.21 seconds of CPU and a checkout 0.13 seconds, MariaDB and nginx included. CPU sets the ceiling.

Two changes that beat the server settings

PHP's JIT compiles busy code to machine code; it cut page times by about 10% and raised checkout throughput by 18%. Try it on a copy of the shop first and watch the PHP error log. The theme mattered far more. WooCommerce's classic Storefront theme (4.6.2) built the product page in 91 ms instead of 161 and the shop page in 90 ms instead of 213, with 79 KB of HTML against 168 KB. In our lab the theme moved an uncached page more than any server setting did, so speed work starts with the theme and plugins. If you would rather hand that job over, our managed WordPress service (€100 a month, described near the end) includes speed optimisation.

OPcache settings that fit more than one shop

# as root
cat > /etc/php/8.4/fpm/conf.d/99-shop-opcache.ini <<'INI'
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
INI
systemctl restart php8.4-fpm

To see how full OPcache is, ask PHP-FPM itself, because the command-line PHP keeps a separate cache. Do it before you add the page cache further down: our first try came back from the nginx cache with old numbers.

# as root, after opening a few shop pages
cat > /var/www/shop/opcache-check.php <<'PHP'
<?php $s = opcache_get_status(false);
printf("%d scripts, %d MB used, interned strings %.1f of %d MB\n",
  $s['opcache_statistics']['num_cached_scripts'],
  $s['memory_usage']['used_memory'] / 1048576,
  $s['interned_strings_usage']['used_memory'] / 1048576,
  $s['interned_strings_usage']['buffer_size'] / 1048576);
PHP
curl -s -H "Host: shop.test" http://127.0.0.1/opcache-check.php
rm /var/www/shop/opcache-check.php

On Debian's defaults it printed 1469 scripts, 55 MB used, interned strings 8.0 of 8 MB, so the buffer for repeated names such as classes and functions was full. With the file above: 1469 scripts, 79 MB used, interned strings 14.5 of 32 MB. One shop fits the defaults, as the timings showed; several shops on one server would not. revalidate_freq=60 checks for changed files once a minute instead of every 2 seconds, so a plugin update can take a minute to appear.

Redis object cache: fewer queries, little time saved

# as root
apt-get install -y redis-server php8.4-redis
printf "maxmemory 128mb\nmaxmemory-policy allkeys-lru\n" >> /etc/redis/redis.conf
systemctl restart redis-server
systemctl restart php8.4-fpm
cd /var/www/shop
sudo -u www-data wp plugin install redis-cache --activate
sudo -u www-data wp redis enable
sudo -u www-data wp redis status

The status showed Status: Connected and Client: PhpRedis (v6.2.0), with Redis 8.0.2 and the Redis Object Cache plugin 3.0.0. The product page fell from 92 database queries to 8 and the checkout from 69 to 3, yet PHP time stayed near 186 ms and 120 ms, because MariaDB on the same server answered from memory. Redis helps more with a big catalogue or a database on another machine, and it used only 18 MB, so keep it. It is not what makes a checkout fast.

PHP-FPM workers sized to RAM

PHP-FPM keeps a pool of PHP processes, called workers, each serving one request at a time, and Debian's default pool allows 5. More workers add no CPU, but they matter when requests wait on something outside the server, such as a payment or shipping API. We simulated that with a test address that waited 0.5 seconds, kept 10 such requests running, and measured normal pages beside them:

With 5 workers, the waiting requests held every worker and shoppers queued behind them. The opposite case matters too: when nothing waits on an outside service, extra workers only lengthen the queue, because the CPU is already full, as our Prishtina news-site test showed. A shop calls payment and shipping services during checkout, so give it the spare workers. Raising the limit costs little memory:

# as root
sed -i -E 's/^pm.max_children = .*/pm.max_children = 16/' /etc/php/8.4/fpm/pool.d/www.conf
grep -E '^pm' /etc/php/8.4/fpm/pool.d/www.conf
systemctl restart php8.4-fpm
ps -C php-fpm8.4 -o rss=,cmd= | grep pool

grep showed pm.max_children = 16, and ps listed workers at about 90 to 100 MB. Most of that is OPcache and libraries shared by all workers; each one's private memory was 17 to 18 MB. With 15 workers busy, the whole shop, MariaDB and Redis included, used about 470 MB of the 2 GB. Our suggested starting points, with room for admin pages and imports: 16 workers on 2 GB, 24 on a VPS Mini with 4 GB, 40 on a VDS Small with 8 GB. Then watch free -m for a week.

Page cache rules that keep carts private

Guests who only browse should get cached pages; that is where the 0.6 ms comes from. The danger is caching too much. Some nginx snippets for WordPress add fastcgi_ignore_headers Cache-Control Expires Set-Cookie, and we tried that line without WooCommerce exclusions. Shopper A added the hoodie and opened /cart/. Shopper B, a new visitor, opened /cart/ and got A's page from the cache (X-Cache: HIT), with A's item and cart token in the HTML. A third visitor who clicked the add-to-cart link received A's session cookie, and with it A's cart. This server block skips the cache for cart, checkout and account pages, API and payment callbacks, query strings, and every visitor with a cart or a login:

# as root: /etc/nginx/sites-available/shop
fastcgi_cache_path /var/cache/nginx/shop levels=1:2 keys_zone=SHOP:32m inactive=60m max_size=512m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
    listen 80;
    server_name shop.test;
    root /var/www/shop;
    index index.php;
    client_max_body_size 64m;

    set $skip_cache 0;
    if ($request_method = POST) { set $skip_cache 1; }
    if ($query_string != "") { set $skip_cache 1; }
    if ($request_uri ~* "^/(cart|checkout|my-account)/|^/wp-admin/|^/wp-json/|wc-api|wc-ajax") { set $skip_cache 1; }
    if ($http_cookie ~* "woocommerce_items_in_cart|woocommerce_cart_hash|wp_woocommerce_session_|wordpress_logged_in_") { set $skip_cache 1; }

    location / { try_files $uri $uri/ /index.php?$args; }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_cache SHOP;
        fastcgi_cache_valid 200 10m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-Cache $upstream_cache_status;
    }
}

# as root
mkdir -p /var/cache/nginx/shop
nginx -t && systemctl reload nginx

# as any user, on a second machine
curl -s -o /dev/null -D - http://shop.test/product/hoodie-with-logo/ | grep -i x-cache
curl -s -c cart.txt -o /dev/null "http://shop.test/?add-to-cart=12"
curl -s -b cart.txt -o /dev/null -D - http://shop.test/cart/ | grep -i x-cache
curl -s -b cart.txt -o /dev/null -D - http://shop.test/product/hoodie-with-logo/ | grep -i x-cache

nginx -t reported syntax is ok. A new visitor's first product view showed X-Cache: MISS, the next HIT. With a cart cookie, cart and product page both showed BYPASS, and shopper B now saw an empty cart. Ten connections fetched 953 cached pages per second, limited by our one-vCPU load generator. Cached pages can show an old price for up to 10 minutes (fastcgi_cache_valid), so shorten it or empty /var/cache/nginx/shop after a price change. Our Dublin WordPress guide sets up the Nginx Helper plugin, which deletes a page's cached copy when you edit it; check that it does the same for your products before you rely on it. For HTTPS, see our reverse proxy guide; for Apache, Caddy and LiteSpeed caches, our WordPress stack benchmark.

iDEAL | Wero, Bancontact and the payment callback

Dutch shoppers expect iDEAL. Belgian shoppers expect Bancontact, which handled 382 million online payments in 2024, 90% of them on a smartphone (Bancontact Payconiq Company). WooCommerce includes neither; a payment plugin adds them. Two on wordpress.org list both methods, checked on 14 October 2026:

• Mollie Payments for WooCommerce 8.1.11, with 100,000+ active installs. Its changelog records the rename to "iDEAL | Wero" in version 8.1.4 and a separate Wero method in 8.1.9.
• WooCommerce Stripe Payment Gateway 11.0.1, with 700,000+ active installs.

We did not test either, because both need a merchant account, but the hosting side is clear. The shopper pays in the bank app, then the provider confirms the payment by calling your server in the background, a so-called webhook. If a firewall rule, a "coming soon" page, password protection or a cache rule blocks that call, the shopper has paid but the order stays pending. Keep the shop on HTTPS, keep /wc-api/ and /wp-json/ out of the cache, place a real test order after every server change, and keep the plugin updated through the Wero switch.

GDPR with a Dutch server

Names, addresses and order histories are personal data under the GDPR. On an Amsterdam server they stay in the EU, supervised by the Autoriteit Persoonsgegevens, and if they leak in a way that puts customers at risk, GDPR Article 33 expects the shop owner to report it there within 72 hours of finding out. The location answers "where is our data?"; updates, admin passwords and a privacy policy are still your job. RS Computers LLC, a Kosovo company, acts as your processor under our Data Processing Agreement. Harden the server with our Debian 13 security guide, then pick from the Amsterdam plans.

Sizing a WooCommerce server in Amsterdam: plans and cities

On the three VPS plans, the vCPUs are shared with other customers on the same host, so their speed can vary a little with the host's load. The three VDS plans reserve dedicated vCPUs for you. All six come with NVMe storage, unmetered traffic, their own IPv4 address and IPv6 (a whole /48 per server in Amsterdam), and moving up a size later takes a short reboot from the client area.

A rough sizing rule: our 2 vCPUs built about 10 uncached product pages per second. If a shopper with a full cart opens a page every 15 seconds, that serves about 150 such shoppers at once. Four vCPUs should roughly double it, and on a VDS they stay yours when the host is busy. Our lab shop had exactly the resources of a VPS Micro, and both of its vCPUs were full under load, which is why a shop that lives from its orders gets a VPS Mini in the table.

Our comparison of the three cities covers the trade-offs, and availability by city is on the plans page. Moving an existing shop? Our migration guide shows how to pause new orders for the final copy, and the WordPress VPS overview lists everything included.

Rather sell than tune? Managed WordPress for €100 a month

Theme tests, PHP-FPM workers and cache rules are work many shop owners would rather not do between orders. For them, RS Computers offers managed WordPress on demand for €100 a month: speed optimisation, WordPress customisation and managing your WordPress, plus SEO and AI search optimisation, getting the shop indexed by Google, Bing and other search engines, and advice on which articles to write for your business, all on your own RS Computers server in Amsterdam, Dublin or Prishtina. To order it, or to ask whether it fits your shop, email info@rscomputers-ks.com or message us on Telegram.

Frequently asked questions

Is Amsterdam a good location for WordPress hosting in the Netherlands and Belgium?

Yes. Amsterdam is home to AMS-IX, which listed 903 connected networks in October 2026, and in RS Computers' ping.pe test on 6 October 2026 probes reached our Amsterdam server in 6.6 ms from Frankfurt, 6.7 ms from London and 9.3 ms from Paris. For a shop, server time matters more: an uncached product page took 163 ms in our lab.

How much RAM does a WooCommerce shop need on a VPS?

Less than many guides suggest. In our lab, WooCommerce 11.2.1 with 1,018 products, 15 busy PHP workers, MariaDB and Redis used about 470 MB, and each worker added 17 to 18 MB of its own memory. By that measure, a VPS Mini with 4 GB has room for about 24 workers and a bigger database cache; in our tests the CPU ran out long before the memory.

Does Redis make WooCommerce faster?

A little. In our lab, Redis object cache cut a product page from 92 database queries to 8, but page times fell by only 2 to 8%, because MariaDB on the same server answered from memory. A lighter theme did more: Storefront built product pages in 91 ms against 161 ms for Twenty Twenty-Five.

Which WooCommerce pages must never be cached?

Cart, checkout and my account, as WooCommerce's caching guide states, plus every request from a visitor with the woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_ or wordpress_logged_in_ cookie. In our lab, an nginx cache that ignored WooCommerce's Cache-Control header served one shopper's cart and session cookie to other visitors.

Can a self-hosted WooCommerce shop accept iDEAL and Bancontact?

Yes, through a payment plugin such as Mollie Payments for WooCommerce or WooCommerce Stripe Payment Gateway, both on wordpress.org and both listing the two methods. iDEAL's move to Wero is due to finish by 31 December 2027, so keep the payment plugin updated. On the server, make sure the provider's webhook calls, its background confirmations to your shop, are never cached or blocked.

Can RS Computers look after my WordPress shop for me?

Yes, on demand. RS Computers offers managed WordPress for €100 a month on your RS Computers server, covering speed optimisation, WordPress customisation, managing WordPress, SEO and AI search optimisation, indexing in Google, Bing and other search engines, and advice on which articles to write. To order or ask, email info@rscomputers-ks.com or message RS Computers on Telegram.

Put the shop next to its buyers

For a shop selling into the Netherlands, Belgium and their neighbours, start in Amsterdam: a VPS Mini for a small shop, a VDS Small when sales come in waves. Then spend your effort where our lab found the time: the theme, enough PHP workers, and a page cache that leaves carts alone. Pick a plan on the Netherlands VPS page, or send us your shop's size on Telegram and we will suggest one.

← All articles