Hosting & Server

PHP OPcache and WordPress Performance

Intermediate
High

What OPcache Does and Why It Matters

Every time a visitor loads a page on your WordPress site, the server reads dozens of PHP files — WordPress core, your theme, every active plugin — and compiles them into instructions the processor can execute. OPcache stores those compiled instructions (called bytecode) in memory so PHP can skip the parsing and compilation steps on subsequent requests. The result is faster page generation with less CPU work.

Mochyon Lightspeed detects this automatically. It checks whether OPcache is enabled, monitors the hit rate, and flags memory pressure that forces scripts to be recompiled.

A typical WordPress installation loads 200–500 PHP files per page request. Without OPcache, the server re-parses every one of those files on every request. With OPcache enabled and properly configured, PHP serves the cached bytecode directly from memory — often cutting backend response time by 30–50%.

When OPcache Is Not Working Well

OPcache Disabled

Some hosting environments ship with OPcache turned off, or it may be disabled as part of a debugging session and never re-enabled. When OPcache is not loaded at all, every request pays the full compilation cost. This is the most impactful scenario — enabling OPcache is one of the single largest performance improvements available on a PHP server.

Low Hit Rate

A hit rate below 90% means PHP is recompiling scripts frequently instead of serving cached bytecode. Common causes include:

  • File timestamp validationopcache.validate_timestamps is on and opcache.revalidate_freq is set to 0, causing PHP to check for file changes on every request
  • Too many scripts — the opcache.max_accelerated_files setting is lower than the number of PHP files on the site, so scripts are constantly evicted and recompiled
  • Frequent deployments — each deployment invalidates the cache if files change, which is expected but can keep the hit rate low on sites that deploy very frequently

Memory Pressure

OPcache has a fixed memory pool (set by opcache.memory_consumption and opcache.interned_strings_buffer). When that pool fills up, PHP must evict cached scripts to make room for new ones. Those evicted scripts will be recompiled on their next request, creating a cycle of eviction and recompilation that undermines the entire purpose of the cache.

Sites with many plugins or large themes are most likely to hit this limit. The default memory allocation (128 MB) is sufficient for most WordPress installations, but sites with 30+ active plugins or heavy page-builder themes may need more.

How to Check Your OPcache Status

Most managed WordPress hosts enable OPcache by default, but the configuration varies. To check your setup:

  • Hosting control panel — many hosts expose OPcache settings in their PHP configuration panel
  • phpinfo() — create a temporary PHP file with <?php phpinfo(); and look for the Zend OPcache section. Remove the file when done.
  • Server status plugins — plugins like OPcache Dashboard or Query Monitor can display OPcache statistics from within WordPress

Key values to check: opcache.enable should be 1, opcache.memory_consumption should be at least 128, and the hit rate (visible in opcache_get_status()) should be above 95% on a warmed-up site.

Further Reading

Related Articles

Newer PHP versions include OPcache improvements alongside raw execution speed gains.
OPcache memory is separate from PHP’s per-request memory limit, but both affect server-side performance.

Need help with this?

Mochyon specializes in WordPress Core Web Vitals optimization. We diagnose, fix, and verify — with a named human accountable for the result.

Get help from Mochyon