A developer migrates a PrestaShop store to a "faster" VPS. Pages stay sluggish. Profiling shows 40% CPU time in PHP compilation. OPcache was disabled in a php.ini copied from old shared hosting. Two lines fixed, TTFB halved — without touching the CPU.
OPcache stores compiled PHP bytecode in shared memory. Without it, every request rereads and recompiles sources. On WordPress — hundreds of included files — impact is massive. It is often the first lever to check, before PHP-FPM, before HTTP/3, before changing hosts.
Verify real state — do not assume
php -i | grep -E 'opcache.enable|opcache.memory'
Or a temporary phpinfo() page in staging. Key points:
| Directive | Role | Warning sign |
|---|---|---|
opcache.enable=1 | Enables cache | 0 in production |
opcache.memory_consumption | Dedicated RAM (MB) | Too low → frequent evictions |
opcache.max_accelerated_files | Max file count | WordPress + Composer > 10,000 → increase |
opcache.validate_timestamps | Recompile if file changed | Off without deploy procedure = ghost bugs |
opcache.revalidate_freq | Check delay | Too high in dev, OK in stable prod |
On PHP 8+, JIT can help on intensive compute; marginal gain on classic CMS — do not prioritize before healthy OPcache.
Pragmatic settings by context
WordPress / shared CMS — confirm enable=1 and max_accelerated_files ≥ 10000; often keep host defaults. VPS with Git deploys — validate_timestamps=0 in production if pipeline reloads PHP-FPM or calls opcache_reset() in CLI after deploy. Ephemeral containers — OPcache resets on every restart; warm-up script may help. Multisite or large monorepo — watch opcache_get_status(): hit rate < 95% → insufficient memory or max_files.
Links with FPM and TTFB
Each PHP-FPM worker benefits from shared OPcache memory. Undersized OPcache forces recompilations and indirectly inflates RAM per worker. Logical sequence: correct OPcache, then Redis object or page cache, then PHP-FPM tuning, then TTFB diagnosis. Ignoring OPcache then doubling workers pays the same mistake twice.
The climax: bytecode cache does not show in PageSpeed
Marketing sells vCPU; OPcache is invisible on the sales sheet — but decisive on bill and real latency. Compare hosts via the directory only after verification.
Decide and move forward without blind spots
Confirm in production that opcache.enable is active and record cache hit rate before any other optimization. Adjust memory_consumption and max_accelerated_files to real project size — WordPress with many plugins quickly exceeds ten thousand files. Document flush procedure on deploy: reload PHP-FPM or CLI reset, never public endpoint. Measure TTFB before and after; only then tune FPM or change hosts.
Frequently asked questions
Is OPcache enabled by default?
On PHP 7+ in production, often yes — but not always on old shared hosting or minimal container images. Check with phpinfo() or php -i | grep opcache.
validate_timestamps On or Off in production?
Off plus deploy that clears OPcache = max performance. On plus frequent deploys = simpler without forgetting cache flush. Choose by pipeline, not universal rule.
Does OPcache replace Redis or page cache?
No. OPcache caches compiled PHP bytecode. Redis caches application data; page cache avoids running PHP. All three complement each other.
How to clear OPcache after deploy?
Reload PHP-FPM, call opcache_reset() in dedicated CLI, or integrate reset in deploy tool — never expose reset() publicly on the web.
Before buying a faster server, one question: Is OPcache enabled and what is its hit rate? If you never looked, you have not optimized PHP yet.