A WordPress site with OPcache disabled, undersized, or constantly resetting makes PHP recompile the same plugin, theme, and core files on request after request. That wastes CPU and pushes TTFB up, especially during WooCommerce traffic spikes. This WordPress OPcache configuration guide gives you production-safe settings, shows where they belong, and explains the deployment trade-off that causes most stale-code incidents.
OPcache is not a WordPress plugin and it is not page caching. It is a PHP extension that keeps compiled PHP bytecode in shared memory so PHP-FPM can execute it without parsing and compiling every file again. Configure it at the PHP level, verify it in the active FPM environment, then monitor whether it has enough memory and file slots for your actual codebase.
What a good OPcache setup looks like
For most production WordPress sites running PHP 8.1 through 8.3, start with this configuration in the PHP INI file loaded by PHP-FPM:
opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=20000 opcache.max_wasted_percentage=10 opcache.validate_timestamps=1 opcache.revalidate_freq=0 opcache.save_comments=1 opcache.jit=0 opcache.jit_buffer_size=0This is a sensible baseline, not a magic block to paste blindly. A small brochure site may run comfortably with 128 MB and 10,000 cached files. A plugin-heavy WooCommerce store, multisite network, or agency stack with builders, payment extensions, and monitoring tools often needs 256 MB and 20,000 or more files.
The target is simple: high cache hits, no memory restarts, no hash-table restarts, and enough room to deploy code safely. If OPcache runs out of memory or file entries, PHP has to discard cached work and rebuild it. The site may still function, but performance becomes inconsistent precisely when traffic is high.
Where to configure OPcache for WordPress
Do not put OPcache directives in `wp-config.php`. WordPress loads after PHP has already initialized OPcache, so those values are too late to reliably affect the cache.
On a self-managed server, the active file is commonly an `opcache.ini` file under a PHP configuration directory, or a PHP-FPM pool configuration supplied by your control panel. Typical locations vary by operating system and PHP version, such as:
/etc/php/8.3/fpm/conf.d/10-opcache.ini /etc/php/8.3/fpm/php.ini /opt/cpanel/ea-php83/root/etc/php.d/10-opcache.iniFirst, identify the configuration PHP-FPM is actually using. A command-line `php --ini` result is useful, but it may not match FPM if your server has multiple PHP versions. Your hosting panel's PHP settings page, a protected `phpinfo()` page, or the WordPress Site Health information screen is usually a better way to confirm the live web configuration.
After changing the INI file, gracefully reload PHP-FPM. The service name depends on your system:
sudo systemctl reload php8.3-fpmA reload recycles workers cleanly and ensures new requests use the revised settings. Restarting every service on the server is unnecessary and can create avoidable downtime.
Choose settings based on your site, not a blog post
`opcache.memory_consumption`
This is the shared memory allocation in megabytes for compiled PHP code. Start at 128 MB for lean sites and 256 MB for most serious WordPress builds. Move to 512 MB only when the status data shows a real need or when a large multisite installation cannot retain its working code set.
More memory is not automatically faster. It just prevents cache churn. On a constrained server, allocating 512 MB without checking total RAM can contribute to swapping, which is far more damaging than a modest OPcache allocation.
`opcache.max_accelerated_files`
This controls how many PHP scripts OPcache can track. WordPress core alone is not the problem. The count rises quickly with plugins, page builders, WooCommerce extensions, translation files, custom mu-plugins, and deployment releases left on disk.
Use 10,000 as a floor for a simple production site and 20,000 for a typical managed WordPress or WooCommerce environment. If the cache reports a full hash table, increase this setting during your next maintenance window. Do not guess based on the number of active plugins.
`opcache.interned_strings_buffer`
Interned strings reduce repeated memory use for identical strings in PHP code. The default is often too conservative for modern WordPress stacks. Set 16 MB as a practical baseline. A large multisite or application-like WordPress build may benefit from 32 MB, but verify the status before increasing it.
`opcache.save_comments`
Leave this enabled. Some WordPress plugins and their dependencies inspect PHP docblocks or annotations. Disabling comment retention can produce failures that look like plugin bugs and are painful to diagnose after an update.
JIT settings
Keep PHP JIT disabled for ordinary WordPress workloads. JIT can help specific CPU-bound application code, but WordPress requests are usually limited by database queries, remote API calls, disk access, cache misses, and PHP worker contention. It adds another variable without delivering a dependable PageSpeed or checkout gain.
The deployment choice that matters most
`opcache.validate_timestamps` determines whether PHP checks source-file modification times. With the recommended setting of `1` and `opcache.revalidate_freq=0`, PHP checks for changed files on each request. That adds a very small filesystem metadata check but greatly reduces the chance of serving old plugin, theme, or core code after an update.
Some teams set `opcache.validate_timestamps=0` for maximum consistency and slightly less filesystem work. That is valid only when deployments always perform an explicit OPcache reset or PHP-FPM reload. If your update process includes clicking Update in wp-admin, emergency plugin rollbacks, or multiple people making changes, disabling timestamp validation is an unnecessary operational risk.
If validation is disabled, treat cache clearing as part of every release. On a single dedicated application environment, a controlled `opcache_reset()` mechanism can work. On shared PHP-FPM services, be careful: OPcache scope follows the PHP service or container, not an individual WordPress install. Resetting it may affect other sites using that same PHP runtime.
Verify that OPcache is active and healthy
Do not stop after seeing `opcache.enable => On`. A cache can be enabled and still be too small to help consistently.
Use a protected PHP status page or a server monitoring tool to inspect `opcache_get_status()`. Never expose that output publicly. It can reveal filesystem paths, script names, and server details. The fields worth watching are memory usage, interned string usage, number of cached scripts, hits, misses, and restart counters.
Healthy production behavior usually looks like this: the hit rate climbs toward 99% after normal traffic warms the cache, `oom_restarts` stays at zero, `hash_restarts` stays at zero, and cached script count remains below the configured maximum. A miss spike immediately after a PHP-FPM reload is normal. Persistent misses under steady traffic are not.
If you only have SSH access, inspect the loaded configuration first:
php -i | grep -E 'opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files|opcache.validate_timestamps'Remember that this checks the CLI SAPI. It confirms the available PHP configuration, but it does not prove the FPM service serving web traffic has loaded the same file. Confirm the web SAPI separately before declaring the job complete.
When OPcache does not fix slow WordPress
OPcache lowers repeated PHP compilation overhead. It will not repair a slow database query, a remote inventory API holding checkout open, exhausted PHP workers, an overloaded CPU, or a missing object cache. If TTFB remains high after OPcache is healthy, profile the request path instead of increasing memory indefinitely.
For WooCommerce, pay particular attention to uncached cart, checkout, account, and AJAX requests. These requests reach PHP and the database even when full-page caching works well elsewhere. OPcache helps make their PHP work cheaper, but Redis object caching, optimized queries, sufficient PHP workers, and fast CPU cores determine how well the store holds up under concurrent orders.
That is why infrastructure still matters. A correctly sized OPcache on high-frequency hardware such as the AMD Ryzen 9950X systems used by WP Tango removes one recurring source of PHP waste, but it cannot compensate for a server that is oversold or a stack with no visibility into FPM saturation.
Set OPcache once, measure it after real traffic and deployments, and revisit it when the site changes materially. The best configuration is the one that keeps code warm, updates predictable, and your PHP workers focused on work visitors can actually feel.
