OPcache and JIT in PHP 8.3 production — what actually moves the needle

PHP 8.3's OPcache is one of the highest-ROI configuration changes in the entire stack. The default config is dev-friendly (frequent revalidation, modest memory). The production-correct config is a small change that routinely cuts CPU usage by 30-40% on Laravel and WordPress workloads. JIT is the murkier sibling — sometimes a clear win, sometimes neutral, occasionally a regression.

This is what we ship and why.

The production config

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

The single most-impactful flag is validate_timestamps=0. It tells OPcache to never check if a file has changed — it just trusts what's in the cache. Trade-off: deploys require an explicit opcache_reset() or PHP-FPM reload, which your deploy pipeline should be doing anyway.

The full write-up covers:

• Why validate_timestamps=0 belongs in every production config
• Sizing memory_consumption and max_accelerated_files for your codebase
• JIT modes (function, tracing) — and the workloads where each helps
• When JIT genuinely hurts (PHP-as-templating, mostly-I/O workloads)
• Reading the opcache_get_status() output to verify it's actually doing its job
• Cold-start strategies for ephemeral containers (preloading vs lazy)

We ship this configuration on every managed PHP install.