Hosting WordPress on a VPS gives you full control — and full responsibility for performance. A stock WordPress install runs dozens of PHP and database queries per page view, and on a small VPS that is a recipe for slow TTFB and CPU spikes. The fix is not one cache but a stack of them. This guide explains the four caching layers that matter on a VPS — OPcache, object cache, page cache, and CDN — in the order you should implement them, with the exact settings and commands for each.<\/p>\n\n\n\n
Every PHP request recompiles your theme and plugin files unless OPcache is enabled. On PHP 8.x it ships built in; you just need to size it. In Verify with WordPress stores options, transients, and fragments of repeated queries in the database by default. An object cache keeps those in memory. On Debian\/Ubuntu: Use the Query Monitor plugin afterwards to check the cache hit rate — healthy installs see 80–95% of queries served from Redis instead of MySQL. Allocate 64–128 MB of Redis memory on a 1–2 GB VPS; that is more than enough for most sites.<\/p>\n\n\n\n Even with OPcache and Redis, every visit still runs PHP. A page cache stores the final HTML output so anonymous visitors never touch PHP at all. With nginx as your front server, FastCGI caching is the cleanest approach — no plugin needed. Key directives in your server block:<\/p>\n\n\n\n With this in place, anonymous page views produce a TTFB of 20–80 ms instead of 300–800 ms, and your PHP-FPM workers stay free for logged-in traffic and admin requests. Just remember to purge the cache on post updates — a stale homepage is worse than a slow one.<\/p>\n\n\n\n The final layer offloads JavaScript, CSS, images, and fonts to a CDN so your VPS only serves HTML and API traffic. Fingerprinted assets (with a hash in the filename) can be cached aggressively with Caching the wrong responses is worse than caching nothing. Never serve cached pages to logged-in users, active commenters, or anyone with a WooCommerce cart — personalized content must bypass the page cache entirely. The standard nginx approach keys on cookies: Implement the layers in order and verify each one before moving on: php.ini<\/code>:<\/p>\n\n\n\n\n
opcache.enable=1<\/code> — turn it on<\/li>\nopcache.memory_consumption=128<\/code> — enough for a typical plugin-heavy install<\/li>\nopcache.max_accelerated_files=10000<\/code> — covers most themes plus plugins<\/li>\nopcache.revalidate_freq=60<\/code> — check files for changes at most once a minute<\/li>\n<\/ul>\n\n\n\nphp -i | grep opcache.enable<\/code> after restarting PHP-FPM. This layer alone typically cuts PHP execution time by 30–50% with zero downside.<\/p>\n\n\n\nLayer 2: Object Cache with Redis<\/h2>\n\n\n\n
sudo apt install -y redis-server php-redis<\/code>, then install the Redis Object Cache plugin from the command line:<\/p>\n\n\n\nwp plugin install redis-cache --activate && wp redis enable<\/code><\/p>\n\n\n\nLayer 3: Page Cache (Nginx FastCGI Cache)<\/h2>\n\n\n\n
\n
fastcgi_cache_path \/var\/run\/nginx-cache levels=1:2 keys_zone=wpcache:10m inactive=60m;<\/code> — cache storage and zone<\/li>\nfastcgi_cache wpcache;<\/code> — enable the cache for this server<\/li>\nfastcgi_cache_valid 200 60m;<\/code> — cache successful pages for an hour<\/li>\nfastcgi_cache_bypass $http_cookie;<\/code> — skip the cache for logged-in users (combined with a cookie check for comments\/cart)<\/li>\nfastcgi_cache_purge<\/code> — purge the page when a post is updated (via the nginx-helper plugin or a custom rule)<\/li>\n<\/ul>\n\n\n\nLayer 4: CDN for Static Assets<\/h2>\n\n\n\n
Cache-Control: public, max-age=31536000<\/code>. A CDN does not change server TTFB, but it dramatically improves first paint and time-to-interactive for visitors far from your data center, and it spares your VPS bandwidth and CPU on image-heavy pages.<\/p>\n\n\n\nLayer<\/th> Typical effect<\/th> Effort<\/th><\/tr><\/thead> OPcache<\/td> −30–50% PHP execution time<\/td> 5 minutes<\/td><\/tr> Object cache (Redis)<\/td> 80–95% fewer DB queries<\/td> 15 minutes<\/td><\/tr> Page cache (FastCGI)<\/td> TTFB 20–80 ms for anonymous visits<\/td> 30 minutes<\/td><\/tr> CDN<\/td> Faster global load, less VPS bandwidth<\/td> 1 hour<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n What Not to Cache<\/h2>\n\n\n\n
fastcgi_cache_bypass $cookie_wordpress_logged_in;<\/code> combined with fastcgi_cache_key \"$scheme$request_method$host$request_uri$cookie_wordpress_logged_in\";<\/code>. Admin pages under \/wp-admin\/<\/code> should bypass as well. Set a short cache lifetime (5–15 minutes) for archive and taxonomy pages so recent posts appear quickly, and purge the cache whenever a post, page, or comment is published — the nginx-helper plugin wires WordPress hooks to purge endpoints automatically, and wp cache flush<\/code> clears the object cache during deploys. Finally, exclude sitemap.xml<\/code> and robots.txt<\/code> from aggressive caching so search engines always see fresh metadata.<\/p>\n\n\n\nPutting It Together<\/h2>\n\n\n\n
curl -sI https:\/\/your-site\/ | grep -E 'HTTP|x-cache'<\/code> shows the page-cache header, Query Monitor confirms the Redis hit rate, and a before\/after run of wrk -t2 -c20 -d30s https:\/\/your-site\/<\/code> quantifies the gain. All four layers fit comfortably on a 1 GB VPS — Redis at 64–128 MB, the nginx cache on disk, and OPcache inside PHP’s own memory. If you are choosing hardware for a WordPress project, the VPS feature comparison at virtualserversvps.com<\/a> highlights plans with enough RAM and fast storage for a caching stack, and the provider comparison<\/a> helps you shortlist hosts with reliable NVMe tiers.<\/p>\n\n\n\n