WordPress PHP OPcache: What It Is and Why It Matters for Performance

Every time a visitor loads a page on your WordPress site, PHP must execute a large number of script files: WordPress core files, plugin files, theme files, and more. Without PHP OPcache, the server compiles each of those files from scratch on every single request. OPcache eliminates that redundant work — and it’s one of the single most impactful server-level optimizations you can make for WordPress performance.

What PHP OPcache Does

PHP is an interpreted language. Normally, when your web server processes a PHP request, it goes through these steps for every file it needs to run:

1. Read the .php file from disk
2. Parse the source code into tokens
3. Compile those tokens into opcodes (machine-readable bytecode)
4. Execute the bytecode

Steps 1–3 produce the same result every time for an unchanged file. They’re wasted work on every request after the first.

OPcache (which stands for Opcode Cache) short-circuits that process by storing the compiled bytecode in shared memory after the first compilation. On subsequent requests, PHP skips directly to step 4 — execution — using the cached bytecode. The file is only recompiled if it changes on disk.

OPcache has been bundled with PHP since version 5.5 (released in 2013) and is enabled by default in most PHP 7.x and 8.x installations. The question isn’t whether you have it — it’s whether it’s configured correctly for your workload.

How Much Does It Matter for WordPress?

WordPress is a PHP-heavy application. A typical page load involves bootstrapping WordPress core (dozens of files), initializing every active plugin, loading the theme, and running query logic. The compilation overhead for all of those files adds up quickly on every request.

With OPcache enabled and properly configured:

• PHP execution time for WordPress drops substantially because compilation overhead is eliminated
• Server CPU usage decreases since the server isn’t repeatedly parsing and compiling the same source files
• Throughput (requests per second) improves because each request completes faster

The actual improvement depends on your server hardware, PHP version, number of active plugins, and baseline load, but OPcache is consistently one of the highest-leverage server-side optimizations available for WordPress.

Checking Whether OPcache Is Active

Via a Plugin

The simplest way to check OPcache status on a WordPress site is to install the OPcache Manager plugin by Pierre Lannoy. It provides a dashboard showing whether OPcache is enabled, how much memory is allocated and in use, the hit rate, and individual cached files.

A healthy hit rate is above 99%. If yours is significantly lower, the cache may be undersized or the revalidation frequency may be too aggressive.

Via phpinfo()

You can create a temporary file in your document root:

<?php phpinfo();

Load it in a browser and search for “opcache.” If the extension is enabled, you’ll see a table of configuration values and runtime statistics. Delete the file immediately after — exposing phpinfo() output publicly is a security risk.

Via WP-CLI

If you have WP-CLI access, you can check OPcache status from the command line:

wp eval 'var_dump(opcache_get_status());'

This returns the full status array including memory usage, hit/miss counts, and the list of cached scripts.

Key OPcache Configuration Settings

OPcache is configured through php.ini (or a separate .ini file loaded by PHP). The settings that matter most for WordPress are:

opcache.enable

opcache.enable=1

Enables OPcache. This should be 1. On some hosting environments, it defaults to 0.

opcache.memory_consumption

opcache.memory_consumption=256

The amount of memory (in megabytes) OPcache can use to store cached bytecode. The default is 128MB, which is often too small for WordPress sites with many plugins. If your cached scripts exceed available memory, OPcache will start evicting entries, dropping your hit rate.

For a typical WordPress site with 20–40 active plugins, 128–256MB is usually adequate. For large sites with extensive codebases or many plugins, 256MB or more is appropriate. Check the dashboard or opcache_get_status() to see how much is actually being used.

opcache.max_accelerated_files

opcache.max_accelerated_files=10000

The maximum number of files OPcache can track. WordPress core, themes, and plugins can involve thousands of PHP files. The default of 2000 is too low for many WordPress installations.

Check the actual number of PHP files in your WordPress root with:

find /path/to/wordpress -name "*.php" | wc -l

Set max_accelerated_files to a value larger than that count (rounding up to the nearest valid value — OPcache adjusts to the nearest prime number internally).

opcache.revalidate_freq

opcache.revalidate_freq=60

How often (in seconds) OPcache checks whether cached files have changed on disk. The default is 2 seconds. For production WordPress sites where you’re not making code changes constantly, increasing this to 60 or higher reduces unnecessary disk I/O.

On a production site that only changes code during deployments, you can set this to a large value (or even use opcache.validate_timestamps=0 to disable timestamp checking entirely and manually reset OPcache during deployments). However, if you’re editing files directly on the server, keep the frequency low enough that changes take effect without manual cache clearing.

opcache.interned_strings_buffer

opcache.interned_strings_buffer=16

Memory reserved for interned strings (PHP’s internal string deduplication). WordPress uses a large number of unique string literals across core, plugins, and themes. The default (8MB) is often too small. Setting this to 16MB or 32MB reduces memory overhead for string storage.

opcache.fast_shutdown

opcache.fast_shutdown=1

Enables a faster process for freeing memory at the end of a request. This is enabled by default in PHP 7 and has no separate setting; in older PHP versions it should be set to 1 explicitly.

OPcache and WordPress Deployments

One important operational consideration: when you deploy code changes to a WordPress site, the bytecode cache may still hold compiled versions of the old files. PHP’s default behavior (checking mtime based on revalidate_freq) handles this automatically, but with a delay equal to your revalidation interval.

To force an immediate cache reset after deployment, use WP-CLI:

wp eval 'opcache_reset();'

Or call opcache_reset() via a script run as part of your deployment process. Some deployment tools and WordPress management plugins can trigger this automatically.

OPcache and WordPress Object Cache — Different Things

OPcache is a server-level PHP cache — it caches compiled PHP bytecode in memory. This is distinct from WordPress’s object cache, which caches database query results and computed data at the application level.

Both types of caching are important for WordPress performance, and they operate on entirely different layers:

Cache Type	What It Stores	Where	Plugin Examples
OPcache	Compiled PHP bytecode	Shared memory (process-level)	None — configured at server level
Object Cache	Database query results, computed data	Memory (Redis, Memcached) or disk	Redis Object Cache, W3 Total Cache
Page Cache	Full rendered HTML output	Disk or memory	WP Rocket, WP Super Cache, LiteSpeed Cache

A well-optimized WordPress site uses all three layers. OPcache speeds up PHP execution itself; object caching reduces database round-trips; page caching serves pre-built HTML directly without executing PHP at all for cached requests.

What Managed WordPress Hosting Does Differently

Configuring OPcache correctly requires access to php.ini or server configuration files — something most shared hosting environments don’t expose. On shared hosting, you’re running on whatever PHP configuration the host has set globally, which may or may not be tuned for WordPress workloads.

Managed WordPress hosting platforms like Rocket.net handle this configuration automatically. OPcache is enabled and tuned for WordPress by default, with appropriate memory limits, file count settings, and revalidation intervals based on the actual WordPress codebase structure. Cache resets are handled automatically on plugin updates and deployments.

Beyond OPcache, managed WordPress hosts typically implement the full stack: server-level page caching, Redis object caching, GZIP/Brotli compression, and HTTP/2 or HTTP/3 — all configured and maintained without any manual intervention.

If you’re managing OPcache settings yourself on a VPS or dedicated server, the time investment adds up. On a managed platform, it’s handled for you from day one.

Troubleshooting Common OPcache Issues

Hit rate is low (below 95%)

• Increase opcache.memory_consumption — the cache may be too small and evicting entries
• Increase opcache.max_accelerated_files — you may have more PHP files than OPcache is tracking
• Check whether anything is calling opcache_reset() unnecessarily frequently

Changes to code aren’t taking effect

• Your revalidate_freq is set too high and cached bytecode hasn’t expired
• Call opcache_reset() manually or wait for the revalidation interval to elapse
• If opcache.validate_timestamps=0 is set, timestamps are never checked — you must reset the cache manually on any deployment

Site shows errors after enabling OPcache

• Rare, but some older PHP code uses patterns that interact poorly with OPcache
• Disable OPcache temporarily to confirm it’s the cause, then update the relevant plugins or themes
• Ensure PHP version compatibility — OPcache behavior has improved across PHP 7.x and 8.x versions

Memory usage hits 100%

• The cache is full and entries are being evicted — increase opcache.memory_consumption
• Use opcache_get_status() to see oom_restarts and hash_restarts counts; non-zero values confirm the cache is under memory pressure

Summary

PHP OPcache is a foundational server-level optimization that every WordPress site should be running. It eliminates the repeated compilation overhead that PHP would otherwise incur on every request, reducing PHP execution time and server CPU usage across the board.

The key configuration parameters — memory allocation, maximum file count, and revalidation frequency — need to be sized appropriately for WordPress sites rather than left at their defaults. A site with many plugins or a high-traffic workload will exhaust default OPcache limits quickly, resulting in cache misses that undermine the performance benefit.

For sites running on managed WordPress hosting like Rocket.net, this is handled automatically — OPcache is enabled, configured, and maintained as part of the platform. For sites on self-managed servers, auditing your current OPcache configuration and comparing it against the settings above is a worthwhile investment in server-side performance.