WordPress VPS Optimization: Nginx FastCGI Cache, OPcache & Database Basics

The biggest WordPress speed gains on a VPS come from caching in three layers: PHP OPcache so scripts are not recompiled, an Nginx FastCGI cache so most visitors never reach PHP, and a persistent object cache plus a healthy database for everything that must run dynamically. This guide shows each layer with settings drawn from the official documentation.

Why caching first

The WordPress Advanced Administration Handbook on optimization says caching plugins store posts and pages as static files to cut server processing, and that this can improve performance several hundred times for fairly static pages. It also lists opcode caches such as OPcache, a persistent object cache that saves database trips, MySQL or MariaDB with the InnoDB engine, and a CDN. It adds that hosting limits what you can do, and that faster storage, more CPU or RAM help. On a VPS with root access, which every VPSWala plan includes, you control all of those layers.

Layer 1: PHP OPcache

PHP's manual documents the OPcache directives and their defaults. The ones worth checking on a WordPress server:

The manual notes that when validate_timestamps is disabled you must call opcache_reset(), call opcache_invalidate() or restart the web server to pick up file changes. A WordPress site that updates plugins from the dashboard is usually best left with timestamp validation on.

opcache.enable=1
opcache.memory_consumption=192
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Check usage afterwards with an OPcache status page or php -i | grep opcache and raise a limit only if the cache is full.

Layer 2: Nginx FastCGI page cache

The Nginx FastCGI module documentation defines the directives. fastcgi_cache_path sets the directory and a keys_zone, where about 8,000 keys fit in 1 MB. Data not accessed within inactive (ten minutes by default) is removed, and max_size caps the cache. A starting configuration:

fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WP:50m
                   inactive=60m max_size=1g;

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-login.php|/cart|/checkout|/my-account")
                                           { set $skip_cache 1; }
    if ($http_cookie ~* "wordpress_logged_in|comment_author|woocommerce_items_in_cart")
                                           { set $skip_cache 1; }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_cache WP;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
        fastcgi_cache_valid 200 301 302 60m;
        fastcgi_cache_valid 404 1m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache_use_stale error timeout updating http_500 http_503;
        fastcgi_cache_lock on;
        add_header X-Cache $upstream_cache_status;
    }
}

Points from the documentation worth knowing: fastcgi_cache_bypass and fastcgi_no_cache take the same kind of conditions, and using both stops cached copies being served to, or stored from, the requests you exclude. fastcgi_cache_use_stale with updating lets Nginx serve a stale copy while a fresh one is being fetched, reducing load on PHP. fastcgi_cache_lock on lets only one request populate a new cache element at a time. The documentation also states that a Set-Cookie response header prevents caching, so if your theme or a plugin sets a cookie on every page, either remove it or the cache will stay empty. The X-Cache header above makes that easy to see.

curl -sI https://example.com/ | grep -i x-cache
curl -sI https://example.com/ | grep -i x-cache

The first request should report MISS and the second HIT.

Layer 3: object cache and the database

For logged-in users, carts and admin screens, page caching is skipped, so database speed matters. The Handbook recommends InnoDB, the default engine, and converting old MyISAM tables. Install Redis or Memcached and a compatible object cache plugin so options and query results stay in memory. Keep the database on fast storage and watch slow queries before adding plugins.

Order of work and common mistakes

1. Update PHP to a supported version and enable OPcache.
2. Add FastCGI caching with the bypass rules above and confirm HIT headers.
3. Add an object cache for dynamic pages.
4. Optimize images and consider a CDN for static files.

• Caching the cart or checkout, so customers see each other's baskets.
• Forgetting to purge or wait for expiry after a design change.
• Stacking a caching plugin on top of Nginx caching without understanding which one answers.

Pick a plan from VPSWala's KVM VPS range, or consider the 9950X VPS plans if single-thread PHP speed is your bottleneck. Plans are unmanaged unless agreed in writing, so patching and monitoring stay with you.

Sources

• WordPress Advanced Administration Handbook: Optimization
• nginx: Module ngx_http_fastcgi_module
• PHP Manual: OPcache configuration