WordPress VPS Optimisation: Page Caching, Object Caching and MySQL Memory

WordPress on a VPS gets fast in a predictable order: measure first, then add a full-page cache, then a persistent object cache, then size PHP-FPM and the database for your memory, and only then chase individual plugins. Each step removes work from the next one, so doing them out of order wastes time.

Step 1: measure

Record time to first byte and page weight with PageSpeed Insights and your browser's network panel, for the home page, a post, a product page if you run WooCommerce, and the logged-in dashboard. web.dev explains how to read TTFB and what inflates it. Keep these numbers so you can prove each change helped.

Step 2: full-page caching

Most WordPress visits are anonymous and can be served from a cache without running PHP at all. Options on a VPS include Nginx's FastCGI cache or a caching plugin that writes static files. Exclude carts, checkouts, account pages and logged-in users.

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WP:100m inactive=60m;
# inside the PHP location block
fastcgi_cache WP;
fastcgi_cache_valid 200 301 10m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Step 3: persistent object cache

WordPress's object cache normally lasts only for one request. A Redis-backed object cache keeps query results between requests, which helps logged-in users, WooCommerce and the dashboard, none of which a page cache helps. The WordPress Advanced Administration Handbook covers caching layers and where each applies.

Step 4: PHP-FPM workers

Set pm.max_children from memory, not from a guess. Measure memory per PHP worker under load, reserve memory for MySQL, Redis and the operating system, and divide what is left by the worker size.

Step 5: MySQL or MariaDB memory

The InnoDB buffer pool caches tables and indexes. On a VPS that runs only WordPress, give it a substantial share of the memory that remains after PHP and Redis, enough to hold the working set of your database. MariaDB's documentation explains the setting and how to check its hit rate.

Step 6: plugins and media

• Use a query monitoring plugin on a staging copy to find slow queries and heavy plugins.
• Replace plugins that run expensive queries on every page.
• Serve images in modern formats at the size they are displayed.

Sizing

Monthly INR, excluding GST. All ten sizes, from 1 GB (₹149) to 128 GB (₹19,099), are on the VPSWala cloud VPS plans page. Every plan is KVM with RAID NVMe storage and full root access.

VPSWala's WordPress guidance uses 4 vCPU and 8 GB (VPS 8) as the usual production start for a busy site. PHP rendering benefits from fast single cores, so heavy WooCommerce stores are worth testing on the Ryzen 9 9950X VPS plans.

Responsibilities

VPSWala plans are unmanaged unless you agree otherwise in writing: the host platform, network and provisioning are VPSWala's job, and everything inside the VM is yours. Per the terms of service, off-server backups, control-panel licences, Windows licensing, managed administration and extra IPv4 addresses are quoted separately, and any availability commitment applies only where it is written into your quotation or agreement.

A worked example

A WooCommerce store on a VPS 8 with 8 GB of memory might reserve about 1 GB for the operating system, 512 MB for Redis, 2 to 3 GB for the InnoDB buffer pool, and give the rest to PHP-FPM workers. If each worker uses around 100 MB under load, that leaves room for roughly thirty workers. Measure your own worker size first, because plugins change it a lot.

Mistakes to avoid

• Stacking two page caches that fight each other.
• Caching cart and checkout pages.
• Setting PHP-FPM children so high that the server swaps during a traffic spike.
• Skipping backups because the site is fast. Speed and recoverability are separate problems.

Frequently asked questions

Page cache or object cache: which first?

Page cache first for anonymous traffic. Add the object cache for logged-in users, WooCommerce and admin.

Do I need a CDN?

A CDN helps with static assets and visitors far from the server. It does not fix a slow uncached PHP response.

How do I stop the cache serving stale content?

Purge on publish and update, and keep cache lifetimes short for pages that change often.

Sources

• WordPress Advanced Administration Handbook: Optimization
• WordPress Advanced Administration Handbook: Cache
• Nginx: Module ngx_http_fastcgi_module
• MariaDB: InnoDB Buffer Pool
• web.dev: Time to First Byte (TTFB)