A PHP request should not have to parse and compile the same WordPress files thousands of times a day. When you set up PHP OPcache, PHP stores compiled bytecode in shared memory and reuses it on later requests. The result is less CPU work, faster response times, and more capacity from the server you already pay for.
For WordPress sites, OPcache is one of the first server-side performance settings worth checking. It does not replace page caching, a CDN, database tuning, or a well-configured performance plugin. It handles a different part of the request: the PHP execution layer. That distinction matters, especially for logged-in users, WooCommerce cart activity, admin requests, and other pages that page caches may bypass.
What PHP OPcache does and when it helps#
PHP normally reads a script, parses it, compiles it into bytecode, and executes that bytecode. OPcache keeps the compiled bytecode in memory. On the next request, PHP can use the cached version instead of repeating the parsing and compilation work.
The benefit is most noticeable on PHP applications with many files, including WordPress, WooCommerce, learning platforms, and custom business portals. A small low-traffic brochure site may show only a modest difference in page timing, but it can still use less CPU during traffic spikes. On a busy site, OPcache can be the difference between a server that remains responsive and one that becomes slow under routine load.
OPcache is included with supported PHP releases, but it is not always enabled by the hosting environment. Managed hosting providers often enable it already. Before changing anything, verify the current state. If you have a hosting control panel, look for PHP extensions or PHP options. On a VPS or dedicated server, use the command line and your active PHP configuration.
“`bash php -v php –ini php -m | grep -i opcache “`
The first command confirms the PHP version. The second shows which configuration files the command-line PHP process reads. The third checks whether the OPcache extension is loaded for that PHP binary.
Do not assume command-line PHP and web PHP are using the same configuration. A server may have multiple PHP versions installed, and PHP-FPM can load a different `php.ini` file than the CLI. A temporary PHP information page or a trusted hosting dashboard can confirm the settings used by the website itself. Remove any public PHP information file after testing because it exposes server details.
Set up PHP OPcache in the right configuration file#
On Debian- and Ubuntu-based servers, OPcache is commonly installed as a package matching the PHP version. For example, the package name may resemble `php8.3-opcache`. On RHEL-based systems, it may be provided through the main PHP package set. If the extension is not available, install the version-matched package through your server’s package manager, then enable it.
The exact file location varies. Common locations include `/etc/php/8.3/fpm/php.ini`, `/etc/php/8.3/apache2/php.ini`, or a dedicated file such as `/etc/php/8.3/fpm/conf.d/10-opcache.ini`. Your `php –ini` output is useful, but confirm the web server’s PHP configuration before editing.
Add or adjust the following baseline settings:
“`ini opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=128 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=20000 opcache.validate_timestamps=1 opcache.revalidate_freq=2 opcache.save_comments=1 opcache.jit=0 “`
These values are deliberately conservative for a typical WordPress site. `opcache.memory_consumption` reserves memory for cached PHP bytecode. Starting at 128 MB is reasonable for many small and medium sites. Larger WordPress installations with many plugins, themes, and deployments may need 256 MB or more.
`opcache.max_accelerated_files` controls how many PHP scripts OPcache can track. A modern WordPress installation can contain thousands of PHP files before you account for plugins and dependencies. Setting this too low can reduce the cache hit rate and leave useful files uncached.
`opcache.interned_strings_buffer` reserves memory for duplicate strings shared across scripts. Sixteen megabytes is a practical starting point. For a larger WooCommerce store or plugin-heavy site, 32 MB may be appropriate if monitoring shows pressure.
Keep `opcache.save_comments=1` for WordPress. Some PHP frameworks and tools depend on doc comments or annotations. Disabling comments may save a small amount of memory, but it creates compatibility risk for little practical gain.
PHP JIT is separate from OPcache. It can help certain CPU-intensive workloads, but ordinary WordPress requests rarely benefit enough to justify enabling it. Leave `opcache.jit=0` unless you have tested your specific application under realistic load.
Apply the changes for Apache, Nginx, or PHP-FPM#
Configuration changes do nothing until the PHP process reloads. The command depends on the server stack.
For Apache using the Apache PHP module, restart Apache:
“`bash sudo systemctl restart apache2 “`
For Nginx with PHP-FPM, restart the matching PHP-FPM service. Replace the version with the one installed on your server:
“`bash sudo systemctl restart php8.3-fpm sudo systemctl reload nginx “`
Reloading Nginx is usually not required for an OPcache change, but it is harmless when you are also updating the site stack. The essential step is restarting or reloading PHP-FPM. On production systems with significant traffic, use a graceful reload where your service manager supports it to avoid interrupting active requests.
If you are on shared hosting, do not edit system PHP files unless the provider explicitly allows it. Use the supported PHP settings interface or ask support to enable OPcache. A host that prevents configuration changes may already manage the setting globally.
Verify that OPcache is active#
After restarting PHP, confirm that the website-facing PHP process has OPcache enabled. A restricted admin-only PHP information page can show the OPcache section and its current directives. If your environment supports it, a small protected diagnostic script can report cache status without exposing the full PHP configuration.
Look for these indicators: OPcache enabled, memory not exhausted, a growing number of cached scripts, and a high hit rate after the site receives normal traffic. Immediately after a restart, the hit rate will be low because the cache is empty. That is expected. It should improve as frequently used WordPress files are requested.
A simple command-line check can also confirm that PHP recognizes the extension:
“`bash php -r ‘var_dump(opcache_get_status(false));’ “`
This command only reflects the CLI process when CLI OPcache is enabled, so it is not a substitute for checking PHP-FPM or Apache. It is still useful for confirming that the extension and functions are available.
Choose a safe code deployment policy#
The most common OPcache issue is not performance. It is stale code after a deployment. With `opcache.validate_timestamps=1`, PHP checks whether cached scripts have changed. The `opcache.revalidate_freq=2` setting means it may take up to roughly two seconds for a changed file to be detected. That is a sensible default for WordPress sites where updates can occur through the dashboard.
Some high-traffic production environments set `opcache.validate_timestamps=0` to eliminate file timestamp checks. This can be appropriate when deployments are controlled and always include an OPcache reset or PHP-FPM reload. It is a poor choice for a site where administrators install plugins, update themes, or edit code directly in WordPress. Without a reset, changed code can remain inactive until the cache is cleared.
If you disable timestamp validation, make cache clearing part of every deployment procedure. Restarting PHP-FPM is the most dependable approach. Some deployment tools can call `opcache_reset()`, but that method should be protected and never exposed through a public URL.
Avoid settings that create more work than speed#
OPcache uses RAM. Allocating 512 MB on a small VPS does not make a small site four times faster. It can instead crowd out MariaDB, Redis, PHP-FPM workers, and the operating system file cache. Start with measured requirements, then increase memory only when the OPcache status shows low free memory, high wasted memory, or a full script table.
Also avoid copying a random configuration built for a different PHP version or application. Older recommendations may include directives that have changed behavior or are no longer useful. Keep the configuration short, document why non-default values were selected, and test after PHP upgrades.
For WordPress performance work, OPcache is reliable infrastructure rather than a visible feature. Visitors will not know it is there. They will notice that checkout requests, account pages, and the WordPress admin remain responsive when the site is busy. Set it up carefully, monitor it after real traffic arrives, and let the server spend its resources on useful work instead of compiling the same code again.