If you run WordPress on a VPS, PHP OPcache tuning can make your site load much faster. OPcache stores your PHP files in memory so the server does not have to read them from disk every time. But the default settings are not built for WordPress. This guide shows you how to set the right OPcache values based on your VPS size — whether you have 1 GB, 2 GB, or 4 GB of RAM.
By the end of this tutorial, you will know exactly what to put in your PHP config file. No guesswork. No copy-paste from random blog posts. Just clear steps for PHP OPcache tuning for WordPress VPS setups.
Quick Picks — OPcache Settings by VPS Size
Short on time? Here are the recommended OPcache settings for WordPress VPS based on your server RAM. Pick the row that matches your VPS.
| Setting | 1 GB VPS | 2 GB VPS | 4 GB VPS |
|---|---|---|---|
| opcache.memory_consumption | 128 | 256 | 256 |
| opcache.interned_strings_buffer | 16 | 32 | 32 |
| opcache.max_accelerated_files | 10000 | 20000 | 30000 |
| opcache.validate_timestamps | 1 | 1 | 1 |
| opcache.revalidate_freq | 2 | 2 | 2 |
| opcache.jit | disable | disable | disable |
| opcache.enable_cli | 0 | 0 | 0 |
Best for 1 GB VPS (Single WordPress Site)
A 1 GB VPS has tight memory. Keep OPcache at 128 MB. This leaves enough room for MySQL, PHP-FPM workers, and the OS. Use 10000 for max_accelerated_files. This is enough for WordPress core plus a few plugins.
Best for 2 GB VPS (WordPress + Plugins or WooCommerce Lite)
With 2 GB of RAM, you can give OPcache 256 MB. Set max_accelerated_files to 20000. This handles most plugin-heavy WordPress sites. The interned_strings_buffer at 32 MB helps with sites that use many text strings.
Best for 4 GB VPS (Multi-Site or Plugin-Heavy WordPress)
A 4 GB VPS can run 256 MB of OPcache with 30000 max files. This covers WooCommerce stores, multi-site installs, and 30+ plugins. You could push memory_consumption to 384 MB if needed, but test first.
Why Generic OPcache Settings Fail on Small WordPress VPS Instances
Many guides suggest the same OPcache values for every server. This is a mistake. PHP OPcache tuning for WordPress VPS must match your actual RAM. If you give OPcache too much memory, other services suffer. If you give it too little, the cache fills up and stops working well.
The Problem with Copy-Paste Configurations
You might find a blog post that says “set opcache.memory_consumption to 512.” That value might work on a 16 GB server. On your 1 GB VPS, it will starve MySQL and PHP-FPM. Your site will slow down instead of speeding up. Always size OPcache to your VPS, not to someone else’s server.
How OPcache Competes with PHP-FPM, MySQL, and Redis for RAM
Your VPS RAM is shared. Think of it like a pizza. OPcache gets one slice. PHP-FPM workers get another. MySQL gets a big slice. The OS needs a slice too. If OPcache eats too much, PHP-FPM has fewer workers. Fewer workers mean slower page loads under traffic. This is why PHP OPcache tuning for WordPress VPS is a balancing act.
Step 1 — Diagnose Your Current OPcache Status Before Changing Anything
Before you change any settings, check what you have now. This step is part of smart PHP OPcache tuning for WordPress VPS. You need to know your starting point.
Find Your Active PHP Version and Configuration File Path
Run this command in your terminal:
php -v
This shows your PHP version. Next, find the config file path:
php --ini | grep "Loaded Configuration File"
Write down this path. You will edit this file later. Common paths are /etc/php/8.3/fpm/php.ini or /etc/php.ini.
Check Whether OPcache Is Enabled for Web Requests (Not Just CLI)
OPcache can be on for the command line but off for web requests. To check, create a file called info.php in your WordPress root with this content:
<?php phpinfo(); ?>
Open it in your browser. Search for “OPcache.” If you see the OPcache section, it is enabled for web. Delete the file after checking. It is a security risk.
Read Key Metrics: Hit Rate, Cached Scripts, Free Memory, and Wasted Memory
In the same phpinfo page, look for these values:
- Hit rate: Should be above 90%. Low hit rate means OPcache is too small.
- Cached scripts: Shows how many PHP files are stored.
- Free memory: Should not be near zero.
- Wasted memory: High waste means deleted files still take space.
Count Your Actual PHP Files Across Themes, Plugins, and Must-Use Plugins
Run this command to count PHP files in your WordPress folder:
find /path/to/wordpress -type f -name '*.php' | wc -l
WordPress core alone has about 2,500 to 3,000 PHP files. With 10 plugins, you may have 5,000 to 8,000. With WooCommerce and many extensions, you could reach 20,000 or more. This number tells you what to set for max_accelerated_files.
Step 2 — Calculate Your VPS Memory Budget for PHP OPcache Tuning
Now you know your file count and current status. Next, plan your memory budget. This is the core of PHP OPcache tuning for WordPress VPS.
How Much RAM Does Your WordPress Stack Actually Need?
Here is a rough guide for a typical WordPress VPS:
- OS and system processes: 200–300 MB
- MySQL/MariaDB: 256–512 MB (depends on your database size)
- PHP-FPM workers: 50–80 MB each (5 workers = 250–400 MB)
- Web server (Nginx/Apache): 50–100 MB
- Redis (if used): 50–100 MB
Subtract these from your total RAM. The remainder is what you can give to OPcache.
The OPcache vs. PHP-FPM Workers Trade-Off Explained
More OPcache memory means less room for PHP-FPM workers. More workers let your server handle more visitors at once. But a bigger OPcache means faster responses for each visitor. The trick is to find the right balance. For most WordPress sites, a larger OPcache helps more than extra workers.
A Simple Formula to Set opcache.memory_consumption Safely
Use this formula:
OPcache RAM = Total VPS RAM - (OS + MySQL + PHP-FPM + Web Server + Redis)
For a 2 GB VPS: 2048 – 300 – 384 – 300 – 80 = about 984 MB free. But do not give all of it to OPcache. Keep 50% as a safety buffer. So 256 MB for OPcache is a safe choice. This is the key idea behind PHP OPcache tuning for WordPress VPS.
Step 3 — Configure PHP OPcache for Your WordPress VPS (Step-by-Step)
Now it is time to write the actual config. Follow each step below for proper PHP OPcache tuning for WordPress VPS.
Create a Dedicated OPcache Configuration File (Safe from PHP Upgrades)
Do not put OPcache settings directly in php.ini. PHP upgrades may overwrite it. Instead, create a separate file:
sudo nano /etc/php/8.3/fpm/conf.d/10-opcache-tuning.ini
The exact path depends on your PHP version. The conf.d folder loads extra config files. Name yours with a number prefix so it loads in order.
Set opcache.memory_consumption Based on Your VPS Tier
Add this line to your config file. Use the value from the Quick Picks table above:
opcache.memory_consumption=256
This value is in megabytes. Do not add “M” — just the number.
Set opcache.max_accelerated_files Based on Your Actual File Count
Take the number from Step 1 and add 20% headroom:
opcache.max_accelerated_files=20000
If you counted 8,000 files, set this to 10000. If you counted 15,000, set it to 20000. PHP rounds this to the nearest prime number internally, so round numbers are fine.
Configure opcache.interned_strings_buffer for WordPress
This setting stores repeated text strings in shared memory. WordPress uses many repeated strings. Set it based on your VPS:
opcache.interned_strings_buffer=32
For a 1 GB VPS, use 16. For 2 GB or 4 GB, use 32. This is in megabytes.
Decide on opcache.validate_timestamps: Convenience vs. Deployment Safety
This setting controls whether PHP checks if files have changed:
opcache.validate_timestamps=1
opcache.revalidate_freq=2
With value 1, PHP checks every 2 seconds for file changes. This is safe for WordPress because you update plugins often. Set it to 0 only if you always reset OPcache after every change. For most users, keep it at 1.
Should You Enable JIT (opcache.jit) for WordPress in 2026?
No. Keep JIT disabled for WordPress:
opcache.jit=disable
opcache.jit_buffer_size=0
WordPress is not CPU-heavy. It waits on database queries and external APIs. JIT adds complexity and uses extra memory without real speed gains for WordPress. Save that RAM for OPcache or PHP-FPM instead.
Step 4 — Apply Changes Safely: Syntax Check, Restart, and Rollback Plan
Never restart PHP without checking first. A bad config can crash your site. Follow these steps for safe PHP OPcache tuning for WordPress VPS.
Test Your php.ini Syntax Before Restarting PHP-FPM
Run this command to check for errors:
php -l /etc/php/8.3/fpm/conf.d/10-opcache-tuning.ini
If there are no errors, you will see “No syntax errors detected.” Fix any issues before you continue.
Back Up Your Current Configuration Before Editing
Always keep a backup:
sudo cp /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.backup
If something goes wrong, you can restore this file fast.
Restart PHP-FPM Without Downtime Using the Reload Signal
Use reload instead of restart. Reload does not drop existing connections:
sudo systemctl reload php8.3-fpm
Replace 8.3 with your PHP version. Your site stays online during the reload.
Emergency Rollback: What to Do If PHP-FPM Fails to Start
If PHP-FPM crashes after your changes:
- Check the error log:
sudo journalctl -u php8.3-fpm --no-pager -n 50 - Restore your backup:
sudo cp /etc/php/8.3/fpm/php.ini.backup /etc/php/8.3/fpm/php.ini - Remove your custom file:
sudo rm /etc/php/8.3/fpm/conf.d/10-opcache-tuning.ini - Restart PHP-FPM:
sudo systemctl restart php8.3-fpm
Step 5 — Verify That Your OPcache Tuning Is Actually Working
After applying changes, confirm they work. This final check completes your PHP OPcache tuning for WordPress VPS setup.
Confirm New Settings Are Loaded with phpinfo() or WP-CLI
Use WP-CLI to check your settings:
wp config get --fields=opcache.memory_consumption
Or use the phpinfo method from Step 1 again. Check that your new values appear.
Monitor Cache Hit Rate After 24 Hours of Traffic
Wait 24 hours. Then check the hit rate again. It should be above 95%. If it is below 80%, your OPcache is too small. Increase memory_consumption by 64 MB and try again.
Check for Cache Evictions and Wasted Memory Growth
In phpinfo, look at “blacklist misses” and “wasted memory percentage.” If wasted memory is above 10%, consider a restart. If you see many evictions, increase max_accelerated_files.
Compare WordPress Response Times Before and After Tuning
Use a tool like GTmetrix or WebPageTest. Test your site before and after. You should see faster Time to First Byte (TTFB). A drop of 30–50% in TTFB is common after proper PHP OPcache tuning for WordPress VPS.
How to Handle WordPress Updates, Plugin Installs, and Theme Changes
WordPress updates change PHP files. Your OPcache needs to know about these changes.
If validate_timestamps=1: Automatic Invalidation Workflow
With validate_timestamps set to 1, PHP checks file timestamps every 2 seconds. When you update a plugin, PHP sees the new timestamp and loads the fresh file. No manual action needed. This is the easiest path for most WordPress VPS users.
If validate_timestamps=0: Manual OPcache Reset After Every Update
If you set validate_timestamps to 0, you must clear OPcache after every update. Otherwise, visitors see old code. This is risky unless you have an automated deploy script.
How to Reset OPcache Safely via WP-CLI (No Risky Public Scripts)
Use WP-CLI to reset OPcache without exposing a public script:
wp cache flush
Or reload PHP-FPM:
sudo systemctl reload php8.3-fpm
Both methods clear the cache safely.
PHP-FPM Reload vs. Full Restart — Which One Clears OPcache?
A reload keeps existing workers alive. They keep their OPcache. A full restart kills all workers and starts fresh. A full restart always clears OPcache. A reload may not. If you need a guaranteed cache clear, use a full restart during low-traffic hours.
PHP OPcache Tuning for Multi-Site WordPress on a Single VPS
Running multiple WordPress sites on one VPS changes the math.
Shared OPcache Pool Across Multiple WordPress Installations
If all sites use the same PHP-FPM pool, they share one OPcache. The total PHP file count is the sum of all sites. Count files across all WordPress folders and set max_accelerated_files accordingly. You may need 50000 or more.
How Multiple PHP Versions Create Separate OPcache Pools
If Site A uses PHP 8.2 and Site B uses PHP 8.3, each has its own OPcache. They do not share memory. Plan your memory budget for each PHP version separately.
Identifying Which Site Is Causing Cache Churn or Memory Pressure
Check the OPcache status for each PHP version. The site with the most PHP files and the most file changes causes the most churn. Move that site to its own PHP-FPM pool if it disrupts other sites.
Ongoing Monitoring and Maintenance for Your WordPress VPS OPcache
OPcache tuning is not a one-time task. Check it regularly.
A Simple Weekly OPcache Health Check Command
Create a small PHP script that prints OPcache stats. Run it weekly via cron:
php -r 'print_r(opcache_get_status(false));'
Look for hit rate, free memory, and wasted percentage. If hit rate drops below 90%, investigate.
When to Increase or Decrease Your OPcache Settings
- Increase memory_consumption if hit rate is below 90% or you see frequent restarts.
- Increase max_accelerated_files if you add many new plugins.
- Decrease memory_consumption if free memory is always above 80% and your VPS is low on RAM.
What OPcache Cannot Fix (Slow Queries, External APIs, Bloated Plugins)
OPcache only speeds up PHP file loading. It does not fix slow database queries, heavy external API calls, or bloated plugins that run slow code. If your site is still slow after OPcache tuning, look at these areas next. Use a tool like Query Monitor to find slow queries.
Troubleshooting Common PHP OPcache Issues on WordPress VPS
“No Performance Improvement” After Tuning — What to Check
If your site is not faster after PHP OPcache tuning for WordPress VPS, check these:
- Is OPcache actually enabled for web requests? (Use phpinfo to confirm.)
- Is your hit rate above 90%?
- Are you using a caching plugin that conflicts with OPcache?
- Is the real bottleneck a slow database or external API?
OPcache Keeps Restarting or Evicting Scripts Prematurely
This means your memory_consumption is too small. OPcache fills up and restarts to make room. Increase it by 64 MB. Also check if max_accelerated_files is large enough for your file count.
WordPress Showing Stale Code After Plugin or Theme Update
This happens when validate_timestamps is set to 0. Either change it to 1, or reset OPcache after every update. Use sudo systemctl reload php8.3-fpm to clear the cache.
PHP-FPM Crashing After OPcache Configuration Change
This usually means a syntax error or an impossible value. Check the PHP-FPM error log. Common mistakes include using “M” in the value (just use the number) or setting memory_consumption higher than available RAM. Restore your backup and try again with smaller values.
FAQ: Common Questions About PHP OPcache Tuning for WordPress VPS
Q: Do I need OPcache if I already use a caching plugin like WP Rocket?
A: Yes. Caching plugins create static HTML pages. OPcache speeds up the PHP that runs when a page is not cached. They work together. You need both.
Q: Can OPcache use too much RAM and crash my server?
A: Not directly. But if you give OPcache too much RAM, other services like MySQL run out of memory. That can cause crashes. Always follow the size-based guide above.
Q: How often should I restart OPcache?
A: With validate_timestamps=1, you rarely need to restart. Only restart when you see high wasted memory or after major updates if something looks wrong.
Q: Does OPcache work with PHP-FPM and Nginx?
A: Yes. OPcache works with any PHP SAPI. It is built into PHP 7.0 and above. It works with PHP-FPM, Nginx, Apache, and LiteSpeed.
Q: Should I enable opcache.enable_cli?
A: No. Keep it at 0 for WordPress. Enabling OPcache for CLI can cause issues with WP-CLI cron jobs and waste memory on a small VPS.
Conclusion and Final Recommendations
PHP OPcache tuning for WordPress VPS is one of the easiest wins for site speed. Here is what to remember:
- Match OPcache to your VPS size. A 1 GB server needs different values than a 4 GB server.
- Count your PHP files first. Set max_accelerated_files above your actual count.
- Do not starve other services. OPcache shares RAM with MySQL and PHP-FPM.
- Keep validate_timestamps at 1 unless you have a solid deploy process.
- Skip JIT for WordPress. It does not help and wastes memory.
- Always back up before editing. Test syntax before restarting.
- Monitor after changes. Check hit rate after 24 hours.
Start with the Quick Picks table above. Apply the settings. Check your hit rate. Adjust as needed. Proper PHP OPcache tuning for WordPress VPS can cut your TTFB in half. Your visitors will notice the difference.