If your WordPress or PHP site is already on decent hosting, has a caching plugin installed, and still feels sluggish on every page load, there's a good chance nobody ever turned on OPcache. It's one of the biggest free performance wins in PHP, and on a lot of cPanel accounts it's sitting there disabled or barely tuned. Here's what it does, how to tell if yours is off, and how to turn it on properly.

Symptom: PHP Pages Feel Slow Even With Caching Plugins Installed

You've got WP Super Cache or LiteSpeed Cache running, your database queries are fine, and your VPS isn't under heavy load — but PHP-heavy pages (checkout, admin, anything not served straight from a full-page cache) still drag. Time to First Byte is high even on cache misses, and CPU usage climbs faster than it should for the amount of traffic you're getting.

That gap is a strong hint that PHP itself is doing more work than it needs to on every single request, which is exactly what OPcache is built to fix.

Cause: PHP Recompiles Your Code on Every Request By Default

PHP is an interpreted language, but it doesn't run your .php files directly — it first compiles them into bytecode, then executes that bytecode. Without OPcache, that compilation step happens fresh on every single page request, for every file your script touches. On a WordPress site with a few hundred plugin and core files loaded per request, that's a lot of repeated work for code that hasn't changed since the last visitor loaded the page five seconds ago.

OPcache stores the compiled bytecode in shared memory after the first compile, so subsequent requests skip straight to execution. It's a completely different layer from object caching (Redis/Memcached, which caches database query results) or page caching (LiteSpeed/Varnish, which caches whole rendered HTML pages) — OPcache speeds up PHP's own execution, underneath both of those.

Plenty of shared hosting stacks ship with OPcache available but disabled, or enabled with a memory allocation so small it can't hold a full WordPress codebase, which quietly defeats the purpose.

Fix: Check, Enable, and Tune OPcache in cPanel

Step 1 — Check whether OPcache is already running

The fastest check is a one-line script. Create a file called opcache-check.php in your site's root with this content:

<?php
var_dump(function_exists('opcache_get_status') ? opcache_get_status() : 'OPcache not loaded');

Load it in your browser. If you get back "OPcache not loaded", the extension isn't active for that PHP version at all — talk to your host, since on SkyServer accounts it should be available on every supported PHP version. If you get an array back with keys like opcache_enabled, memory_usage, and opcache_statistics, it's loaded — check whether opcache_enabled is true or false. Delete this file once you're done; it exposes internal server info and shouldn't sit in a public web root long-term.

Step 2 — Turn it on and set memory in MultiPHP INI Editor

  1. Log into cPanel and open MultiPHP INI Editor under the Software section.
  2. Select your domain from the dropdown at the top — settings are per-domain if you're running multiple PHP versions across sites.
  3. Switch to the Editor Mode tab (rather than the basic toggle view) so you can set specific values, not just on/off switches.
  4. Add or update the following lines and click Save:
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.validate_timestamps=1

If your account is on CloudLinux with PHP Selector instead of a plain MultiPHP setup, the same directives go in the PHP Selector's extension/options panel — look for an OPcache section with checkboxes and numeric fields rather than a raw INI editor.

Step 3 — Understand what each setting actually does

DirectiveWhat it controlsRecommended starting value
opcache.memory_consumptionTotal shared memory (MB) for cached bytecode128–256 for WordPress, more for large multi-plugin sites
opcache.max_accelerated_filesMax number of distinct PHP files cached10000 — WordPress with several plugins can exceed the old default of 2000
opcache.revalidate_freqSeconds between checks for changed files2 on active dev sites, 60+ once things are stable
opcache.validate_timestampsWhether OPcache checks for file changes at all1 (on) unless you have a deploy process that clears the cache manually

The two settings people get burned by most are memory_consumption set too low and max_accelerated_files set too low. Both fail silently — PHP doesn't error out, it just starts evicting cached files and recompiling them again, which can end up barely faster than having OPcache off.

Step 4 — Confirm it's actually helping

Reload the same opcache-check.php script from Step 1 after a few minutes of real traffic and look at the stats array:

  • opcache_statistics.opcache_hit_rate should climb toward 95%+ once the cache warms up. Anything consistently under 90% usually means memory or file-count limits are too low and files are getting evicted.
  • memory_usage.used_memory vs free_memory tells you if you're close to the ceiling you set — if used is near 90%+ of the total, raise memory_consumption.
  • opcache_statistics.num_cached_scripts compared against max_accelerated_files tells you if you're bumping the file-count limit.

Delete the check script again once you're satisfied.

Prevention: Don't Let It Silently Drift Out of Tune

  • Re-check after a PHP version change. Switching PHP versions in MultiPHP Manager resets you to that version's default INI — OPcache settings don't automatically carry over.
  • Raise limits as your site grows. Adding a page builder, a security plugin, and a few extra WooCommerce extensions can push a site past 2,000-3,000 files fast — revisit max_accelerated_files after big plugin additions.
  • If you deploy code via Git or SSH, consider setting opcache.validate_timestamps=0 for a small extra speed gain, but only if your deploy process calls opcache_reset() or restarts PHP-FPM afterward — otherwise you'll be staring at a stale version of your own site wondering why your fix didn't take effect.
  • Don't confuse this with object or page caching. OPcache, Redis, and LiteSpeed/Varnish solve different problems and stack cleanly on top of each other — enabling one doesn't replace the need for the others on a busy site.

OPcache is one of the rare server tweaks that's genuinely free performance — no plugin, no extra service to monitor, just PHP doing less redundant work on every request. If you've never checked whether it's actually enabled on your account, it's worth the two minutes it takes.

Frequently Asked Questions

Will enabling OPcache break my site?

No, in normal use. The one real risk is setting opcache.validate_timestamps=0 without a way to clear the cache after deploys, which makes edited files appear not to update. Leave validate_timestamps=1 unless you specifically need that last bit of speed and have a reset process in place.

Is OPcache the same as a caching plugin like WP Super Cache?

No. OPcache caches compiled PHP bytecode at the server level and works underneath every PHP application on the account. WP Super Cache and similar plugins cache the final rendered HTML page. They solve different problems and work well together.

Why don't my OPcache settings save in MultiPHP INI Editor?

Make sure you're editing the same PHP version your domain is actually running (check MultiPHP Manager first), and that you're saving in Editor Mode rather than the toggle view, which only exposes a limited subset of directives.

How much memory should I give OPcache?

128MB is a reasonable floor for a single WordPress install; 256MB is a safer default if you're running several plugins or multiple sites under one PHP-FPM pool. Check memory_usage in the status output after a day of traffic and adjust up if usage is consistently near the ceiling.

Does this help static HTML sites too?

Only indirectly — OPcache only speeds up PHP execution, so a purely static site (no PHP at all) won't see any change. It helps anything that runs PHP on each request: WordPress, Laravel, custom PHP apps, and similar.