WordPress Hosting in Ireland: A Dublin VPS for Irish and UK Websites, with a Page-Speed Lab

For WordPress hosting in Ireland, put the site on a server in Dublin with a page cache in front of WordPress: Irish visitors are then a few milliseconds of fibre away, UK visitors about 11 ms, and the data stays in the EU under the GDPR. RS Computers runs KVM VPS and VDS servers in Dublin, and to show the rest of the job we tuned a WordPress 7.1.3 brochure site on a test server with 2 vCPUs and 2 GB of RAM. Server response fell from 82 ms to 1.5 ms, the home page got 40% lighter, and its Lighthouse mobile score rose from 88 to 96. Every command we ran is below, followed by which plan suits which Irish site.

Key facts, checked on 14 October 2026:

• Google rates a page as good when its Largest Contentful Paint (LCP, the moment the biggest image or text block appears) comes within 2.5 seconds, INP (how fast the page reacts to a tap or click) is 200 ms or less and CLS (how much the layout jumps while loading) is 0.1 or less, at the 75th percentile of visits (web.dev). For time to first byte (TTFB) the rough guide is 0.8 seconds (web.dev).
• Only 48% of mobile websites passed all three Core Web Vitals in 2025, and 44% had a good TTFB on mobile (HTTP Archive Web Almanac 2025).
• WordPress 7.1.3, released on 6 October 2026, is the current version (wordpress.org).
• The EU renewed its adequacy decisions for the UK on 19 December 2025, and both last until 27 December 2031 (ICO).
• Ireland's Data Protection Commission recorded 6,521 valid breach notifications and 16,160 new cases from individuals in 2025 (DPC annual report, 30 June 2026).
• The .ie registry's live counter showed 353,361 registered .ie domains (weare.ie).

Who gains from WordPress hosting in Ireland, and who should look elsewhere

Distance sets a floor that no tuning removes: fibre adds about 1 ms of round trip per 100 km (Lightwave), and Cork, Galway and Limerick are a few hundred kilometres from Dublin. WonderNetwork's averages from Dublin, published on 6 October 2026 and measured between its own test servers, not ours, are 11 ms to London, 26 ms to Frankfurt and 84 ms to New York. In our own ping.pe test that day, a probe in Dublin reached our Amsterdam server in 21.0 ms. Our Ireland and Netherlands pages list the full sets.

What an Irish, British or American visitor waits for

Before the first byte of a page arrives, a new HTTPS visitor pays the round trip three times: once to connect, once for the encryption handshake (TLS) and once for the request itself. We put those Dublin round trips into our lab with netem, a Linux tool that delays packets, and timed fresh HTTPS connections (TLS 1.3, HTTP/2) to the WordPress test site, taking the median of 11 for each row:

Read the table as three round trips plus server time. The page cache in step 1 removes the server time; only a nearer server, or a CDN edge near the visitor, removes the round trips. So an Irish shop on a Dublin server starts its pages roughly 50 ms sooner for Irish buyers than the same shop in Amsterdam, while British visitors see almost no difference. Mainland Europe is better served from Amsterdam, Kosovo and the Balkans from Prishtina, and our server location guide runs the same sum for every European city pair.

Some hosts sell "Irish hosting" from servers in London, so check the location before you buy (the last FAQ answer below shows a quick test). If Ireland is your market, the Dublin VPS page lists every plan with Ireland preselected.

Irish rules a WordPress site runs into

Ireland is an EU member state, so the GDPR applies directly to what a WordPress site collects: contact forms, comments, sign-ups and orders. The regulator is the Data Protection Commission, which also enforces the 2011 ePrivacy Regulations behind cookie banners. For British customers, the EU adequacy decisions run to the end of 2031 and the ICO treats every EEA country as adequate under UK GDPR, so a UK business can keep its site and customer data in Dublin without extra transfer contracts.

A .ie domain is a separate decision. The registry checks that each applicant has a real connection with the island of Ireland, Northern Ireland included, which one document such as an Irish passport, a CRO number or a VAT number can prove (.ie registry); it does not ask where the site is hosted. For Google, a country domain is a strong sign of the target country, while server location "is not a definitive signal" (Google Search Central). Choose Dublin for speed and data location, and .ie for the audience signal.

One WordPress trap: themes and plugins that load fonts, analytics or maps from other companies send each visitor's IP address to them, wherever your server is. Our Twenty Twenty-Five test site served its own font, and Lighthouse counted zero third-party bytes; check yours in the browser's Network tab. For EU-hosted statistics, see our Umami and Plausible comparison.

The lab: one Irish brochure site, four changes

The test site ran in an Incus container on our test host in Amsterdam, limited to 2 vCPUs and 2 GB of RAM like our VPS Micro plan (processor models can differ between hosts). The software was Debian 13 with Nginx 1.26.3, PHP 8.4.26 with OPcache and MariaDB 11.8.6. WordPress 7.1.3 used the default Twenty Twenty-Five theme, no page builder, WordPress's theme unit test data (59 posts, 23 pages, 37 media files) and a typical small-business home page: a full-width cover photo, three photos in columns and the latest posts.

We started from Debian's defaults: no page cache, gzip for HTML only. Server timings are the median of 21 curl requests on the server itself, without the network. Browser figures are the median of three Lighthouse 12.8.2 mobile runs per step.

The 20-visitor rows come from four ApacheBench runs. With every page built by PHP, the median wait was 0.8 to 0.9 seconds before any network delay, right at Google's TTFB guide value: that is what a newsletter or a local news mention does to an uncached site.

Measure your own site first

Run this from your computer before you change anything and after each step, with your domain in place of our lab hostname dublin.test:

# as any user, on Linux or macOS: ten requests, print the median time to first byte in seconds
for i in $(seq 10); do curl -s -o /dev/null -H 'Accept-Encoding: gzip, br' -w '%{time_starttransfer}\n' http://dublin.test/; done | sort -n | sed -n 5p

# after step 1: is the page coming from the cache?
curl -s -D - -o /dev/null http://dublin.test/ | grep -i x-cache

On the lab server the first line printed 0.002984 with the cache and 0.078020 with it bypassed; the second printed X-Cache: HIT. From your own computer, the round trips from the table above come on top. If the numbers stay bad, our guide on why a VPS is slow covers CPU, disk and memory checks.

Step 1: a page cache in Nginx

A page cache stores the finished HTML of each page, so the next visitor gets a copy instead of waiting for PHP and the database. Nginx has one built in, the FastCGI cache:

# as root
mkdir -p /var/cache/nginx
cat > /etc/nginx/conf.d/wp-cache.conf <<'EOF'
fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WP:32m inactive=60m max_size=512m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
EOF

We skipped the mkdir on the first try, and nginx -t refused the config with mkdir() "/var/cache/nginx/wp" failed, because Debian 13 has no /var/cache/nginx folder. Next comes the server block. This is our complete lab version, WebP part from step 3 included; keep any HTTPS lines Certbot added to yours (our SSL guide covers certificates):

# as root: /etc/nginx/sites-available/dublin
server {
    listen 80;
    server_name dublin.test;
    root /var/www/dublin;
    index index.php;
    client_max_body_size 64m;

    # do not cache admin pages, POSTs, searches or logged-in visitors
    set $skip_cache 0;
    if ($request_method = POST) { set $skip_cache 1; }
    if ($query_string != "") { set $skip_cache 1; }
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*\.php|/feed/|sitemap") { set $skip_cache 1; }
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_items_in_cart") { set $skip_cache 1; }

    location ~* ^/wp-content/uploads/.+\.(jpe?g|png)$ {
        add_header Vary Accept;
        try_files $uri$webp_suffix $uri =404;
    }

    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 WP;
        fastcgi_cache_valid 200 301 302 10m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache_use_stale error timeout updating http_500;
        fastcgi_cache_lock on;
        add_header X-Cache $upstream_cache_status;
    }
}

Leave out the wp-content/uploads location until step 3, because it needs the webp.conf file created there. Nginx ignores the site file in sites-available until it is linked into sites-enabled (without the link, our second test install kept showing the Nginx welcome page), so link it, then test and reload:

# as root
ln -s /etc/nginx/sites-available/dublin /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

The home page dropped from 82.3 ms to 1.5 ms on the server. The first visit after the cache is emptied still takes 76 to 82 ms, because the page must be built once, and a search like /?s=bridge showed X-Cache: BYPASS, as intended. With 20 visitors at once the median wait fell from about 0.8 seconds to 1 ms at this stage; step 2 explains why it ended at 24 ms.

Edited pages must leave the cache. The free Nginx Helper plugin by rtCamp (version 2.4.1, 200,000+ installs on wordpress.org) deletes the right cache files when you save a post. We set it up with WP-CLI, run as the web server user:

# as root, in the WordPress folder; WP-CLI runs as the www-data user
cd /var/www/dublin
sudo -u www-data wp plugin install nginx-helper --activate
sudo -u www-data wp config set RT_WP_NGINX_HELPER_CACHE_PATH /var/cache/nginx/wp/ --type=constant
sudo -u www-data wp option update rt_wp_nginx_helper_options '{"enable_purge":1,"cache_method":"enable_fastcgi","purge_method":"unlink_files","purge_homepage_on_edit":1,"purge_page_on_mod":1,"purge_archive_on_edit":1}' --format=json

A warning that WP-CLI could not create /var/www/.wp-cli/cache/ is harmless. The last line equals ticking Enable Purge, "nginx Fastcgi cache" and "Delete local server cache files" under Settings, Nginx Helper. Editing our About page turned its X-Cache from HIT to MISS, and the next visitor saw the new title at once.

One surprise: Lighthouse stayed at 88. On an idle server, 80 ms of PHP time is small next to the 150 ms round trips Lighthouse simulates for a phone; the cache pays off with crowds and distance. Rather not edit Nginx files? This is the speed work our managed WordPress service does for €100 a month (details below). WP Super Cache is a plugin route, and our WordPress stack benchmark load-tests five web server stacks with their page caches, that plugin included.

Step 2: compress text with gzip and Brotli

Debian's Nginx has gzip on, but its list of file types is commented out, so CSS and JavaScript go out at full size. Brotli is a newer compression method that current browsers accept and that packs text a little tighter than gzip:

# as root
apt install -y libnginx-mod-http-brotli-filter
cat > /etc/nginx/conf.d/compression.conf <<'EOF'
# gzip is already "on" in nginx.conf; Debian only compresses HTML until you list more types
gzip_vary on;
gzip_comp_level 5;
gzip_types text/css application/javascript text/javascript application/json image/svg+xml text/xml application/xml text/plain;

# Brotli from the libnginx-mod-http-brotli-filter package
brotli on;
brotli_comp_level 5;
brotli_types text/css application/javascript text/javascript application/json image/svg+xml text/xml application/xml text/plain;
EOF
nginx -t && systemctl reload nginx

Listing the types is the big win; Brotli adds about 7% over gzip. Lighthouse rose from 88 to 91, First Contentful Paint fell from 1.7 s to 1.4 s and LCP from 3.8 s to 3.5 s.

Compression costs CPU, because Nginx compresses each cached page again for every visitor. With 20 visitors at once on 2 vCPUs, the cached home page went out about 3,040 times a second at Brotli level 1, 1,190 at level 4, 840 at level 5 and 650 at level 6, while the HTML shrank only from 21.7 KB to 15.1 KB. Level 4 or 5 is the sensible middle; 840 pages a second is about three million an hour.

Step 3: serve WebP photos

In the first audit, WebP versions of the photos were Lighthouse's biggest suggested saving, an estimated 152 KiB. WebP stores the same photo in fewer bytes, and current browsers all show it. We converted every JPEG and PNG in the uploads folder with Google's cwebp tool and kept the originals for old browsers:

# as root
apt install -y webp
cd /var/www/dublin/wp-content/uploads
sudo -u www-data find . -type f \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' \) -exec sh -c 'for f; do [ -f "$f.webp" ] || cwebp -quiet -q 80 -metadata none "$f" -o "$f.webp"; done' sh {} +
cat > /etc/nginx/conf.d/webp.conf <<'EOF'
# browsers that accept WebP get photo.jpg.webp when it exists
map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}
EOF

Add the wp-content/uploads location from step 1 and run nginx -t && systemctl reload nginx again. The 154 image files went from 14.1 MB to 7.7 MB, 45% smaller, in 10.5 seconds. A browser that accepts WebP got 82,232 bytes for a photo whose JPEG is 114,532 bytes; other requests still got the JPEG, and WordPress needs no change because image addresses stay the same. Lighthouse rose from 91 to 95, LCP fell from 3.5 s to 2.9 s and the page from 469 KiB to 336 KiB.

The command only converts existing files, so run it again after new uploads, or use the Modern Image Formats plugin from the WordPress Performance Team (version 2.7.1), which its plugin page says creates WebP or AVIF sizes for new uploads. With a CDN in front, check that it respects the Vary: Accept header.

Step 4: two small WordPress tweaks

Lighthouse still flagged the cover and navigation block stylesheets, about 20 KB each, as render-blocking: the browser waits for them before drawing anything. WordPress 7.1.3 writes small stylesheets straight into the page up to 40,000 bytes in total, and raising that limit removes the two requests. We also dropped the emoji script, since current browsers draw emoji themselves. A must-use plugin is one PHP file that WordPress always loads:

# as root
mkdir -p /var/www/dublin/wp-content/mu-plugins
cat > /var/www/dublin/wp-content/mu-plugins/speed.php <<'EOF'
<?php
// Inline small block stylesheets instead of loading them as separate, render-blocking files.
add_filter( 'styles_inline_size_limit', function () { return 100000; } );
// Drop the emoji detection script; every current browser draws emoji itself.
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
EOF
chown -R www-data:www-data /var/www/dublin/wp-content/mu-plugins
php -l /var/www/dublin/wp-content/mu-plugins/speed.php

php -l answered "No syntax errors detected", and the home page source no longer contained wp-emoji. After emptying the cache, First Contentful Paint fell from 1.4 s to 1.1 s and the score reached 96, but LCP only moved from 2.9 s to 2.8 s, still above Google's 2.5 s line. What remains is the cover photo and a 53 KB web font on Lighthouse's simulated slow phone connection (150 ms round trips, 1.6 Mb/s, CPU slowed four times), so a smaller hero image is the next step. Because Lighthouse simulates the network, it cannot see server location; the real-user data in PageSpeed Insights can.

To run Lighthouse yourself, as we did:

# as root: Node.js and Chromium from Debian 13, plus a normal user to run them
apt install -y nodejs npm chromium
useradd -m -s /bin/bash lab

# as the lab user
mkdir ~/lh && cd ~/lh
npm init -y
npm install lighthouse@12
CHROME_PATH=/usr/bin/chromium npx lighthouse http://dublin.test/ --only-categories=performance --chrome-flags="--headless=new --no-sandbox" --output=html --output-path=./report.html

We used Lighthouse 12.8.2 because 13.5.0 needs Node.js 22.19 and Debian 13 ships 20.19.2. Chromium took the container from 293 MB to 720 MB of memory during a run, so on a small production server, run Lighthouse from your own computer instead.

Which plan for WordPress hosting in Dublin

VPS plans have shared vCPUs: a fair share of the host's processor time, which suits sites that are busy now and then. VDS plans have dedicated vCPUs that no other customer uses, which matters when many sites or a shop must stay quick at once. Every plan has NVMe storage, unmetered traffic and its own IPv4 and IPv6 addresses, and Dublin servers get their own /48 of IPv6.

Our lab container matched VPS Micro and used 320 MB of its 2 GB with the cache warm, peaking at 346 MB in the uncached 20-visitor burst, so one brochure site has plenty of room. A shop belongs on VPS Mini because cart and checkout pages are never cached, so every click there keeps a PHP worker busy. An agency is better on VDS Small, whose 4 dedicated vCPUs no other customer shares, with 8 GB of RAM for staging copies. You can upgrade later from the client area with a short reboot; the plans page shows availability by city.

A VPS is not always the right buy. For one small site whose owner never wants to touch a server, Irish shared WordPress hosting is simpler, if the host confirms in writing that its servers are in Ireland. Our WordPress VPS page compares the two line by line, WordPress on a VPS takes a fresh Debian 13 server to a live site step by step, and the migration guide moves an existing one.

Managed WordPress on your RS server: €100 a month

Not every site owner wants to edit Nginx files or run WP-CLI over SSH. For them, RS Computers offers managed WordPress on demand for €100 a month: speed optimisation, WordPress customisation and managing WordPress for you, together with SEO and AI search optimisation, getting your site indexed by Google, Bing and other search engines, and tips on which articles your company should publish, on your own RS Computers server, whichever city it is in. To order or ask a question, email info@rscomputers-ks.com or message us on Telegram.

Frequently asked questions

Is a Dublin server faster for Irish visitors than one in Amsterdam?

Yes. A first HTTPS visit needs about three network round trips before the first byte, so distance counts three times. In our lab a cached WordPress page took 69 ms to start arriving over the 21 ms round trip a Dublin probe measured to our Amsterdam server, against 6 ms with no distance. For UK visitors the two cities are close to a tie.

Does hosting WordPress in Ireland help SEO on google.ie?

Only indirectly. Google says server location "is not a definitive signal" of a site's audience, while a country domain such as .ie is a strong one (Google Search Central). Speed counts more: Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward, and a nearby, cached server improves TTFB and LCP.

How much RAM does a WordPress site need on a VPS?

Less than most people expect. In our lab, WordPress 7.1.3 with Nginx, PHP 8.4 and MariaDB used 320 MB with the cache warm and 346 MB at peak while 20 visitors loaded uncached pages at once. A 2 GB VPS Micro is enough for a brochure site; a WooCommerce shop or several sites should start at 4 GB.

Can a UK business host its WordPress site in Ireland?

Yes. Ireland applies the EU GDPR, the EU's adequacy decisions for the UK last until 27 December 2031, and the ICO treats EEA countries, Ireland included, as adequate under UK GDPR. Personal data can move between a UK business and a Dublin server without extra transfer contracts, though the usual privacy notice and processor agreement still apply.

Does RS Computers manage WordPress for me?

Yes, on demand. RS Computers offers managed WordPress for €100 a month, covering speed optimisation, WordPress customisation, managing WordPress, SEO and AI search optimisation, search engine indexing and article ideas for your company, on your RS Computers server. Email info@rscomputers-ks.com or message @rscomputersks on Telegram to order or ask.

How can I check that a WordPress host's server is really in Ireland?

Ask the host in writing, then test it: ping your site's IP address from the Dublin probe on ping.pe. WonderNetwork's published Dublin to London average is about 11 ms, so a reply well under that suggests a server in Ireland, while 10 ms or more suggests Britain, somewhere further or a long detour. IP whois data shows who owns an address, not where the machine stands.

Your Irish site, a few milliseconds from home

Pick Dublin when your visitors are in Ireland or split with Britain, add a page cache, compress text, serve WebP, and measure before and after with the curl line above. Choose Ireland on the Dublin VPS page: VPS Micro for one site, VPS Mini for several or a shop, VDS Small for an agency. Unsure which? Message us on Telegram.

← All articles