Optimizing Ubuntu VPS in Vietnam for Fast WordPress Globally

The first time I ran a Lighthouse test on a WordPress site hosted in Vietnam and watched the TTFB bounce between 800 ms and 1.4 s for a visitor in Germany, I knew the problem was not the theme. It was the stack. A stock Ubuntu VPS running WordPress out of the box will feel slow to anyone outside Southeast Asia, not because the hardware is weak, but because nothing is tuned. This guide walks through optimizing Ubuntu VPS Vietnam WordPress speed international, step by step, with commands you can run today. By the end, your site should serve a cold request in under 300 ms from anywhere on earth.

Prerequisites

• An Ubuntu 24.04 LTS VPS with full root access. A Linux VPS with at least 2 GB of RAM works; 4 GB is comfortable.
• A domain name pointed at your VPS IP with A and AAAA records set.
• WordPress already installed, either manually or via a stack like LEMP or LiteSpeed.
• Sudo access to a non-root user, or root if you prefer.

Why a Vietnam VPS Can Be Fast for Global Visitors

Most people assume that hosting in Vietnam means slow international traffic. That is only true for an untuned server. The reality is that a WordPress VPS in Hanoi or Ho Chi Minh City sits on the same submarine cables that carry traffic to Singapore, Hong Kong, and the US West Coast. A Vietnam VPS with dedicated IPv4 can reach Europe in 180-220 ms and the US in 200-260 ms. That is not a handicap. It is a starting point.

The real killer is not geography. It is the number of round trips. A default WordPress install makes 10-20 requests to render one page. Each request crosses the Pacific once, sometimes twice if you use a naive CDN setup. Optimizing Ubuntu VPS Vietnam WordPress speed international means cutting those round trips, not moving the server. Cache at the edge, cache in the server, and compress everything in between.

越南 VPS 通过缓存优化可为全球访客提供快速加载的 WordPress 站点。

A Vietnam VPS can deliver fast-loading WordPress sites to global visitors through caching optimization.

Step 1 - Measure Your Current Global Latency First

You cannot fix what you do not measure. Before changing anything, benchmark your site from multiple global locations. I use two tools for this. The first is curl with response time breakdown, the second is a free service like check-host.net which tests from real servers worldwide.

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://yourdomain.com

Run this from your VPS and from your local machine. The numbers you care about are Connect and TTFB. Connect is pure network latency. TTFB is how long the server takes to start responding, which includes PHP execution and database queries. A healthy tuned WordPress site should show a TTFB under 300 ms even on a cold request.

If your Connect time is already under 250 ms from a US test node, your network path is fine. Focus all your effort on TTFB. If Connect is above 300 ms, skip ahead to the CDN section, because no amount of PHP tuning will fix physical distance.

Step 2 - Tune PHP-FPM for WordPress Workload

PHP-FPM is where most WordPress slowness lives. The default pool configuration is conservative and designed for shared hosting safety, not for a single-site VPS. Edit your pool file, usually /etc/php/8.3/fpm/pool.d/www.conf.

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

The pm.max_children value depends on your RAM. Each PHP-FPM worker eats roughly 40-60 MB with WordPress loaded. On a 4 GB VPS, 50 workers means a theoretical ceiling of 2.5-3 GB. That is safe. Do not go above 60 on a 4 GB box or you will start swapping.

Set pm.max_requests = 500 so workers recycle and never leak memory over time. If your site gets heavy traffic, lower this to 300. Restart PHP-FPM after editing.

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm

Verify with php-fpm8.3 -t before restarting if you changed the config, to catch syntax errors early.

Step 3 - Add Redis Object Cache for Database-Backed Pages

WordPress transients and options queries hammer the database on every page load. An object cache in Redis cuts those queries to zero after the first request. Install the Redis server and the PHP extension.

sudo apt install redis-server php8.3-redis -y
sudo systemctl enable --now redis-server

Then install the Redis Object Cache plugin in WordPress and enable it from the settings page. The plugin connects automatically to 127.0.0.1:6379. Verify Redis is actually caching with this command.

redis-cli INFO keyspace
# db0:keys=248,expires=231,avg_ttl=86400

If you see keys in db0, the cache is working. If not, check the plugin settings and confirm the PHP extension loaded with php -m | grep redis. This single change often drops TTFB by 30-40% on query-heavy sites.

Step 4 - Configure Nginx FastCGI Cache or Switch to LiteSpeed

Object caching helps logged-in users and dynamic content, but anonymous visitors should never hit PHP at all. That is what a page cache is for. You have two good paths on an Ubuntu VPS in Vietnam.

If you run Nginx, add a FastCGI cache at the server level. Create a cache directory and add these lines inside your server block.

fastcgi_cache_path /var/run/nginx-wordpress levels=1:2 keys_zone=wpcache:100m inactive=60m;
server {
    ...
    set $skip_cache 0;
    if ($request_method = POST) { set $skip_cache 1; }
    if ($query_string != "") { set $skip_cache 1; }
    if ($request_uri ~* "/wp-admin/|/wp-json/|xmlrpc.php") { set $skip_cache 1; }
    if ($http_cookie ~* "wordpress_logged_in|comment_author") { set $skip_cache 1; }
    location ~ \.php$ {
        fastcgi_cache wpcache;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
    }
}

Test with nginx -t then reload. A cached page should return an HTTP header like X-FastCGI-Cache: HIT. Inspect it with curl -I https://yourdomain.com.

The alternative is to run LiteSpeed and use LSCache, which does page caching and object caching in one plugin. LiteSpeed is noticeably faster at serving static files because it has an event-driven architecture similar to Nginx but with built-in HTTP/2 and HTTP/3 support. If you are on a LiteSpeed VPS, the setup is simpler: install the LiteSpeed Cache plugin, enable cache, and you are done.

Step 5 - Enable Brotli Compression and HTTP/3

Compression is free speed, especially for visitors on mobile networks in Europe or the US. Nginx 1.25+ ships with Brotli support. Enable it in your main nginx.conf.

brotli on;
brotli_comp_level 5;
brotli_static on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

For HTTP/3, add the QUIC listener to your server block alongside the existing listen 443 ssl line.

listen 443 quic reuseport;
listen 443 ssl http2;
add_header Alt-Svc 'h3=":443"; ma=86400';

Verify HTTP/3 works with curl --http3 -I https://yourdomain.com if your curl build supports it, or just check the Alt-Svc header. HTTP/3 eliminates head-of-line blocking on congested international links, which helps visitors on 4G and 5G networks significantly.

Step 6 - Put a CDN in Front for Non-Vietnam Traffic

Here is the honest part. No matter how well you tune your NVMe SSD VPS in Vietnam, a visitor in Brazil or South Africa will see 300 ms of network latency before your server even responds. A CDN fixes that by serving cached static assets and, with a worker, even cacheable HTML from edge nodes close to the visitor.

Cloudflare's free tier is the standard choice. Point your domain to Cloudflare, enable "Cache Everything" on a page rule, and set the Cache Level to "Cache Everything with Edge Cache TTL". This works wonderfully with the FastCGI cache you configured earlier. The edge catches the HTML, your VPS catches the cache miss, and dynamic requests still hit your origin in Vietnam.

One warning, do not use the CDN for the WordPress admin or for logged-in users. Add a page rule that bypasses cache for /wp-admin/ and any URL with wp-* cookies. Otherwise you will debug weird session issues at 2 am.

Step 7 - Tune MySQL or MariaDB for Your RAM Size

If your database is slow, caching only delays the problem. On a 2 GB RAM VPS, the default InnoDB buffer pool is far too small. Set it to about 50% of your available RAM. For a 4 GB VPS, edit /etc/mysql/mariadb.conf.d/50-server.cnf.

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
max_connections = 150

The innodb_flush_log_at_trx_commit = 2 setting trades a tiny amount of crash durability for a significant speed boost on writes. For a WordPress site, this is an acceptable trade-off. Restart MariaDB and verify the buffer size took effect.

sudo systemctl restart mariadb
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Troubleshooting

TTFB still over 500 ms after all this? Check what is slow. Run curl -o /dev/null -s -w "%{time_starttransfer}" on a cached page and an uncached page. If cached pages are fast but uncached are slow, your database or PHP is the bottleneck. Enable the Slow Query Log in MariaDB and check /var/log/mysql/mariadb-slow.log after a few hours of traffic.

Redis keeps losing data or the plugin shows "not connected". Check if Redis is listening on the right socket. The default config listens on 127.0.0.1:6379. If you changed the bind address, the plugin will fail silently. Revert to localhost for security and simplicity.

The FastCGI cache never returns HIT. The most common cause is the set $skip_cache logic catching your test request because of a cookie. Open your browser's incognito mode and test again. Bots also send cookies that can trigger bypass. Review your cookie matching regex.

FAQ

Related articles

• Optimize PHP-FPM for WordPress on a VPS
• Nginx tuning for high traffic, worker, gzip, buffer, cache
• Making WordPress fast with LiteSpeed and LSCache on a VPS
• How much RAM does a WordPress VPS need in 2026
• Set up LEMP stack, Nginx, MariaDB, PHP 8.3 on Ubuntu 24.04