PHP OPcache for WordPress: What It Is and How to Enable It

Every time someone visits a WordPress page that isn’t served from a page cache, PHP has to build that page from scratch. It reads dozens — sometimes hundreds — of PHP files, parses them, and compiles them into bytecode the server can execute. Then it throws that work away and does it all again on the next request.

That repeated compilation is pure overhead. It costs CPU on every single uncached request, and on a busy site it adds up fast. PHP OPcache exists to remove it. It is one of the simplest server-level speed wins available to a WordPress site owner, it is free, and on many hosts it is already there — just switched off or misconfigured.

This guide explains what OPcache actually does, how it differs from the caches you already know, how to check whether it is running on your site, and how to enable and tune it safely.

What OPcache Actually Does

PHP is an interpreted language. When a script runs, the PHP engine first compiles the source code into opcode — a lower-level set of instructions the Zend engine executes. Without OPcache, that compilation happens on every request, for every file involved: WordPress core, your theme, every active plugin, and any libraries they load.

OPcache keeps the compiled opcode in shared memory. The first request after a file changes compiles it once; every later request skips the parsing and compiling steps entirely and runs the cached bytecode straight away. The code itself is unchanged — only the repeated work disappears.

The result is less CPU per request and a faster Time to First Byte, especially on pages that cannot be page-cached: the admin dashboard, WooCommerce cart and checkout, logged-in user pages, and any page your caching plugin deliberately excludes. On shared hosting, where CPU is the scarcest resource, the difference is often noticeable immediately.

OPcache vs Page Cache vs Object Cache

These three caches solve different problems, and confusing them is the most common reason OPcache gets overlooked:

• Page cache stores the finished HTML output of a page, so PHP barely runs at all for cached visitors. It is the biggest win for anonymous traffic.
• Object cache (Redis or Memcached) stores database query results and computed objects, so WordPress asks the database less often.
• OPcache stores compiled PHP code, so the PHP that does run executes faster.

They stack. A page cache helps anonymous visitors; OPcache helps everyone else, including the requests a page cache cannot serve. If you want the full picture of how the layers fit together, see our guide to page cache vs browser cache vs opcode cache in WordPress (https://wpspeedaudits.site/page-cache-vs-browser-cache-vs-opcode-cache-wordpress/).

How to Check If OPcache Is Already Running

Before changing anything, find out where you stand. OPcache ships with PHP 5.5 and later, so on any modern WordPress install it is usually available — but availability and activation are two different things.

Method 1: Your hosting panel

Many hosts expose OPcache as a simple toggle. In cPanel, look under Software for “Select PHP Version” or “MultiPHP INI Editor” and check for an opcache section. Managed WordPress hosts often enable it by default and show its status on a performance or server-information screen. If you find a toggle, that is the easiest path — switch it on and skip the manual configuration below.

Method 2: A phpinfo page

Create a temporary file in your site root called phpinfo.php containing only this line:

<?php phpinfo();

Open it in your browser and search the page for “OPcache”. You will see either a full OPcache section (it is enabled) or a note that the extension is loaded but disabled. Delete the file immediately afterwards — a public phpinfo page leaks server details that attackers can use, so never leave it on a live site.

Method 3: A plugin

If you would rather not touch files, plugins such as OPcache Dashboard or the server-information panel in Query Monitor can report OPcache status from inside wp-admin. This is the safest option if you are not comfortable with FTP or the file manager.

If OPcache is already enabled with sensible defaults, stop here. Tuning beyond the defaults buys little on a typical site, and a working setup should not be disturbed for marginal gains.

How to Enable OPcache

The right method depends on how much control your host gives you.

On managed or shared hosting

Use the host’s toggle first. Managed WordPress hosts and most quality shared hosts enable OPcache server-wide and do not let individual accounts override it — which is fine, because their defaults are usually reasonable. If your host has no toggle and no php.ini access, ask support to enable it. This is a routine request; most hosts will do it without argument, and some already have it on but have not told you.

With php.ini or .user.ini access

If your host gives you a PHP configuration editor, add or adjust these lines. On many shared hosts, a .user.ini file in your site root works where php.ini does not:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.fast_shutdown=1

Save the file, then check with the phpinfo method above that the values took effect. Some hosts require a few minutes, or a PHP process restart, before .user.ini changes apply. If nothing changes after waiting, your host is overriding the file — go back to the support route.

What each setting means

• opcache.memory_consumption — how much shared memory OPcache may use, in megabytes. 128 MB is plenty for most WordPress sites; large sites with many plugins may need 256 MB.
• opcache.max_accelerated_files — the maximum number of scripts OPcache will cache. WordPress core plus a typical plugin set runs to a few thousand files, so 10000 leaves comfortable headroom. Set this too low and OPcache silently stops caching new files.
• opcache.interned_strings_buffer — memory reserved for shared strings, such as class and function names. 8 MB is a sensible default.
• opcache.revalidate_freq — how often, in seconds, OPcache checks whether a cached file has changed on disk. A value of 2 means a changed file is picked up within two seconds. Setting it to 0 forces a check on every request, which defeats part of the benefit; only do that on a development site.
• opcache.validate_timestamps — must be on (1) for revalidate_freq to matter. Some high-performance setups turn timestamp validation off entirely and clear OPcache on deploy instead. That is faster, but it means code changes never appear until someone flushes the cache manually — do not use it unless your deployment process handles the flush.

If you are also upgrading PHP, do that first: a newer PHP version and OPcache together compound the gain, and our guide to upgrading PHP safely in WordPress (https://wpspeedaudits.site/upgrade-php-version-wordpress-speed/) walks through the compatibility checks.

OPcache and Your Caching Plugin

OPcache does not replace your caching plugin, and your caching plugin does not replace OPcache. They operate at different layers:

• WP Rocket, LiteSpeed Cache, or FlyingPress serve cached HTML to anonymous visitors and handle browser caching, minification, and image optimization.
• OPcache speeds up the PHP execution underneath, for every request that reaches PHP.

The same logic applies to object caching. If your site is database-heavy — WooCommerce, membership, large catalogs — adding Redis on top of OPcache tackles a different bottleneck again; see our guide to setting up Redis cache for WordPress (https://wpspeedaudits.site/how-to-set-up-redis-cache-for-wordpress/). Think of it as a stack: page cache for anonymous HTML, object cache for database work, OPcache for PHP compilation. Each layer removes a different kind of repeated work.

Common Problems and Fixes

“I deployed new code but the site shows the old version”

This is OPcache doing its job too well. With timestamp validation on and a revalidate frequency of a couple of seconds, the new code appears within seconds. If it does not, your host may have timestamp validation disabled, or a long revalidate interval. The fix is to flush OPcache after deploys — many hosts provide a button for this, and some caching plugins include an OPcache purge option. As a last resort, restarting PHP clears it completely.

OPcache shows as enabled for the web server but not for the command line

OPcache has separate settings for web requests and CLI. The CLI setting, opcache.enable_cli, is off by default, which is correct: command-line scripts are usually one-off, and caching them wastes memory. Do not be alarmed if a WP-CLI check reports OPcache as disabled while the web check shows it enabled.

OPcache memory keeps filling up

When the cache is full, OPcache stops caching new scripts and performance degrades quietly — there is no error, just slower pages. If your status page shows memory usage pinned near 100 percent, increase opcache.memory_consumption and max_accelerated_files together. A WordPress site with a heavy plugin stack can legitimately need 256 MB.

Your host won’t let you change anything

Some budget shared hosts disable OPcache entirely or lock the settings. If support refuses to enable it and speed matters to you, that is a genuine reason to consider moving hosts — it is a basic, free performance feature, and a host that withholds it is usually cutting other corners too. Our hosting comparison covers what to look for when that decision comes up.

How to Verify It’s Working

Enable OPcache, then measure before you celebrate:

1. Check the status page. A plugin dashboard or phpinfo page should show OPcache enabled, with memory usage climbing as scripts get cached and a healthy hit rate after some traffic.
2. Compare Time to First Byte. Test an uncached page — a logged-in page, or a URL with a cache-busting parameter — before and after enabling OPcache, using the same tool and testing location each time. TTFB on uncached requests is where OPcache shows up most clearly; our TTFB troubleshooting guide (https://wpspeedaudits.site/wordpress-ttfb-too-high-fix/) explains how to read the numbers without fooling yourself.
3. Watch server CPU. On hosts that show resource usage, PHP CPU per request should drop noticeably once the opcode cache warms up. Give it a few minutes of real traffic before judging — a cold cache performs exactly like no cache.

Expect a modest, real improvement rather than a miracle: faster uncached responses, lower CPU usage, and more headroom under traffic spikes. If your pages were already fully page-cached for anonymous visitors, OPcache changes little for those visitors — its value is everything the page cache cannot serve.

When OPcache Won’t Help

OPcache is not a cure-all. It will not fix slow database queries, oversized images, render-blocking JavaScript, or a distant, underpowered server. If your bottleneck is the database, an object cache helps more; if it is images or scripts, front-end optimization matters more. Diagnose first, then apply the fix that matches the bottleneck. OPcache belongs in every WordPress stack as a baseline, but it is one layer of a stack, not the whole answer.

Quick Checklist

• Check whether OPcache is already enabled before changing anything.
• Enable it through your host’s toggle first; use php.ini or .user.ini only if you have access.
• Use sane defaults: 128 MB memory, 10000 files, a 2-second revalidate frequency, timestamp validation on.
• Keep timestamp validation on unless your deployment process flushes OPcache on every release.
• Verify with a status page and a TTFB comparison on an uncached URL.
• Flush OPcache after code deploys if changes do not appear promptly.

OPcache is the rare optimization that is free, low-risk, and genuinely set-and-forget. If it is off on your site, switching it on is one of the highest-return changes you can make in under ten minutes.