5 Quick Tips to Boost WordPress Speed on a VPS

Running WordPress on a Virtual Private Server (VPS) gives you the flexibility to fine‑tune performance, but it also makes you responsible for keeping the site fast and responsive. Even a modest VPS can deliver excellent speed when you apply the right optimisations. Below are five practical steps you can take right now, with exact commands provided for both Debian/Ubuntu (using apt) and AlmaLinux/Rocky/RHEL (using dnf). These are server‑side tweaks that benefit any WordPress site, regardless of your theme or plugins.

1. Use a Lightweight Web Server Stack

WordPress typically runs on the LAMP stack (Linux, Apache, MySQL, PHP). However, swapping Apache for NGINX or enabling Apache’s event MPM can significantly reduce CPU load and improve request handling. NGINX is particularly efficient at serving static files and managing high concurrency.

Install NGINX and PHP‑FPM

First, install the necessary packages. Note that the package names differ slightly between Debian‑based and RHEL‑based systems.

# For Debian/Ubuntu (using apt)
sudo apt update
sudo apt install nginx php-fpm php-mysql

# For AlmaLinux/Rocky/RHEL (using dnf)
# Note: You may need to enable EPEL or Remi repository for specific PHP versions depending on your RHEL version
sudo dnf install epel-release
sudo dnf install nginx php-fpm php-mysqlnd

What these commands do:

• apt update / dnf install epel-release: Updates the package index. On RHEL‑based systems, EPEL (Extra Packages for Enterprise Linux) often provides NGINX and newer PHP modules.
• install nginx: Installs the NGINX web server.
• php-fpm: Installs the FastCGI Process Manager, which runs PHP as a separate, more efficient process that NGINX can communicate with via a Unix socket.
• php-mysql / php-mysqlnd: Installs the MySQL driver required for WordPress to connect to the database.

Once installed, you need to configure NGINX to point to your WordPress directory and enable the PHP‑FPM socket. Below is a minimal server block example:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/html;

    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        # Adjust the socket path if your PHP version is different (e.g., php8.1-fpm.sock)
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # Enable browser caching for static assets
    location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

After saving the configuration, reload NGINX to apply the changes:

sudo systemctl reload nginx

This setup allows NGINX to serve static assets directly and pass PHP requests to the FPM handler, resulting in lower latency and faster execution.

2. Enable OPcache for PHP

OPcache stores pre‑compiled PHP bytecode in shared memory. This eliminates the need to re‑parse and compile PHP scripts on every request, significantly reducing CPU usage and response times. While built into modern PHP versions, it is often disabled by default.

Configure OPcache

You need to uncomment and set the appropriate parameters in your PHP configuration file. The file location varies by distribution.

# For Debian/Ubuntu
# The path may vary based on PHP version (e.g., /etc/php/8.1/fpm/php.ini)
sudo sed -i 's/;opcache.enable=0/opcache.enable=1/' /etc/php/*/fpm/php.ini
sudo sed -i 's/;opcache.memory_consumption=128/opcache.memory_consumption=128/' /etc/php/*/fpm/php.ini
sudo systemctl restart php*-fpm

# For AlmaLinux/Rocky/RHEL
# The path may vary based on PHP version (e.g., /etc/php-fpm.d/www.conf or a specific ini file)
sudo sed -i 's/;opcache.enable=0/opcache.enable=1/' /etc/php-fpm.d/www.conf
sudo sed -i 's/;opcache.memory_consumption=128/opcache.memory_consumption=128/' /etc/php-fpm.d/www.conf
sudo systemctl restart php-fpm

Explanation:

• The sed commands modify the configuration file to enable OPcache (opcache.enable=1).
• opcache.memory_consumption defines the amount of RAM OPcache can use. 128 MB is a sensible default for most standard WordPress installations.
• Restarting the PHP‑FPM service applies the new configuration.

You can verify that OPcache is running by executing:

php -i | grep opcache

Look for the line Opcode Caching => Up and Running in the output.

3. Implement a Full‑Page Cache Plugin

While server‑side optimisations are crucial, WordPress also benefits greatly from application‑level caching. Full‑page cache plugins like WP Super Cache or Cache Enabler generate static HTML files. This allows NGINX to serve the entire page directly without executing PHP code or querying the database, drastically reducing load times.

Installation via WP‑CLI

If you have WP‑CLI installed, you can install and activate the plugin from the command line. This works on any Linux distribution.

# Navigate to your WordPress root directory first
cd /var/www/html

# Install and activate WP Super Cache
wp plugin install wp-super-cache --activate

After activation, log in to your WordPress admin dashboard. Go to Settings → WP Super Cache. Enable Caching On and set the Cache Delivery Method to Simple (or Extra if you are using a CDN). The plugin will now write static files to /wp-content/cache/supercache, which NGINX can serve efficiently.

4. Optimize MySQL / MariaDB Configuration

The database is often the bottleneck for WordPress, especially during traffic spikes. Adjusting key settings in your MariaDB/MySQL configuration can improve query speed and reduce disk I/O pressure.

Sample Configuration Tweaks

Create a new configuration file to override defaults. The path differs by distribution:

# For Debian/Ubuntu (MariaDB)
sudo nano /etc/mysql/mariadb.conf.d/99-wordpress.cnf

# For AlmaLinux/Rocky/RHEL (MariaDB)
sudo nano /etc/my.cnf.d/wordpress.cnf

Add the following lines inside the [mysqld] section:

[mysqld]
# Adjust to 50-70% of available RAM if you have more than 1GB
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
# Disable query cache to avoid contention on multi‑core CPUs
query_cache_type = 0
query_cache_size = 0
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

Save the file and restart the database service:

# For Debian/Ubuntu
sudo systemctl restart mariadb

# For AlmaLinux/Rocky/RHEL
sudo systemctl restart mariadb

What these settings do:

• innodb_buffer_pool_size: This is the most important parameter. It caches data and indexes in memory, significantly speeding up read operations.
• query_cache_type = 0: Disabling the query cache is recommended for modern multi‑core CPUs, as it can cause locking issues and reduce performance.
• max_connections, tmp_table_size, and max_heap_table_size: Increasing these values helps handle traffic bursts more smoothly without forcing queries to disk.

5. Serve Static Assets via a CDN and Enable Browser Caching

Even with a fast VPS, delivering large files like images, CSS, and JavaScript from a Content Delivery Network (CDN) reduces latency for visitors, particularly those located far from your server’s data centre. Most CDNs provide simple integration, but you should also ensure your server sends proper caching headers.

Add Expires Headers in NGINX

The NGINX configuration provided in Step 1 already includes a block for static assets. Ensure it is correctly placed in your server block:

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico|woff2?)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

This tells browsers to keep static files in their local cache for 30 days, preventing repeat downloads. You can pair this server‑side configuration with a CDN such as Cloudflare or another provider. Point your DNS CNAME to the CDN and configure it to cache static assets. For HTML pages, it is generally safer to keep them uncached at the CDN level and let your WordPress cache plugin handle page generation, ensuring dynamic content remains fresh.

Conclusion

Speeding up a WordPress site on a VPS is less about buying more hardware and more about configuring your software stack efficiently. By switching to NGINX with PHP‑FPM, enabling OPcache, implementing a full‑page cache plugin, tuning MariaDB, and leveraging a CDN with proper browser caching, you can achieve noticeable performance gains. We recommend applying these steps one at a time and monitoring response times using tools like ab (Apache Bench) or wrk to ensure each change yields the desired results.