Most WordPress performance conversations jump straight to CDNs, image compression, and caching plugins. Those things matter, but they sit on top of something more fundamental: the PHP version your site runs on and whether OPcache is active. Getting both right costs nothing extra and can noticeably reduce server response times. Getting either one wrong quietly taxes every page load, all day, every day.
This guide explains what upgrading PHP actually buys you, how OPcache and JIT work in plain language, and how to test a version bump without breaking your plugins or your sleep.
Why PHP Version Matters More Than People Think
PHP is the engine that runs WordPress. Every time a visitor hits a page, PHP reads your theme files, queries the database, runs plugin logic, and assembles the HTML response. The version of PHP doing that work is not cosmetic. Each major release has brought genuine performance improvements at the interpreter level, meaning the same WordPress code runs faster with fewer CPU cycles simply because the underlying engine is more efficient.
PHP 8.x as a family represents a substantial improvement over the 7.x line. PHP 8.1 through 8.3 are the current mainstream range. Of those, PHP 8.3 with OPcache enabled is the solid default recommendation for new and existing WordPress sites. It carries the latest performance work, the most recent security patches, and it is well-supported by themes and plugins that have kept up with the ecosystem.
PHP versions also have end-of-life dates. Running an end-of-life version means no more security fixes, which is a straightforward risk. Staying current is both a performance and a security decision.
What OPcache Actually Does
Every time PHP runs a script, it has to read the file from disk, parse it into a format the engine can understand (called bytecode), and then execute it. Without OPcache, that parsing step happens on every single request, for every single script involved in rendering the page. A typical WordPress page load touches dozens of files.
OPcache eliminates the redundant work. The first time a script runs, OPcache compiles it to bytecode and stores that bytecode in shared memory. Every subsequent request for the same script skips the parse step entirely and executes from memory. The files on disk have not changed, so there is no reason to re-read and re-parse them.
The practical result is faster PHP execution and lower CPU pressure across the board. OPcache is bundled with PHP and ships enabled in most modern hosting environments. The question is whether it is configured sensibly.
Key OPcache Settings Worth Knowing
- opcache.memory_consumption: How much shared memory OPcache can use, in megabytes. Too small and it evicts cached bytecode, defeating the purpose. A value of 128 or 256 is reasonable for most WordPress installs.
- opcache.max_accelerated_files: The maximum number of scripts OPcache will cache. WordPress core plus a typical plugin set can involve thousands of files. Setting this too low silently reduces cache effectiveness. A value of 10000 or higher is a safe starting point.
- opcache.validate_timestamps: When enabled, PHP checks whether a file on disk has changed since it was cached. Disabling this gives a speed boost but means you need to manually reset the cache after deployments. Most shared environments leave this enabled for safety.
- opcache.revalidate_freq: How often (in seconds) PHP checks file timestamps when validate_timestamps is on. Setting this to 0 means it checks on every request; a higher value reduces file system calls at the cost of slightly delayed cache invalidation.
You can inspect your current OPcache configuration with the following WP-CLI command, which runs a quick PHP info dump:
wp eval 'phpinfo();' 2>/dev/null | grep -i opcacheOr drop a temporary phpinfo() file on your server and look for the OPcache section. Remove the file immediately after checking.
JIT: The Next Layer, With Caveats
PHP 8.0 introduced a Just-In-Time compiler. JIT goes a step beyond OPcache by compiling bytecode further down to native machine code at runtime, bypassing the PHP interpreter for hot code paths. In theory this sounds like a large win.
In practice, the gains for typical WordPress workloads are modest. WordPress is an I/O-bound application. Most of its time is spent waiting on database queries and file reads, not on CPU-intensive computation. JIT helps most with mathematical and algorithmic workloads. For a standard content site or WooCommerce store, you may see a small improvement or no measurable difference.
That does not mean you should avoid JIT. It is safe to enable and may help if your site does heavier processing (complex product catalogs, lots of in-PHP calculations). Just do not expect it to be the transformative unlock that OPcache is. Enable it, measure, and decide based on your actual numbers.
How to Test a PHP Version Bump Without Breaking Things
Upgrading PHP is the right move, but doing it carelessly on a live site is how you break things at an inconvenient moment. The safe approach takes an extra hour and protects you from surprises.
Step 1: Check Plugin and Theme Compatibility
Before touching anything, review your active plugins and theme. Most reputable plugins document their PHP compatibility in their readme or changelog. Anything that has not been updated in several years is a candidate for trouble. The PHP Compatibility Checker plugin (search the WordPress plugin directory) can scan your codebase and flag code patterns that are known to be problematic on newer PHP versions.
Step 2: Test on a Staging Copy First
Clone your site to a staging environment. If your host provides one-click staging, use it. If not, you can spin up a local copy with a tool like LocalWP or a separate server directory. Switch that copy to the target PHP version, run through your site manually, and check your server error logs.
With WP-CLI on staging you can run a quick check across your plugins:
wp plugin list --format=tableThen activate and test any plugin that does heavy lifting: WooCommerce, form plugins, membership plugins, caching layers. Errors will surface in wp-content/debug.log if you have debugging enabled in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Step 3: Measure Before and After
Use PageSpeed Insights or Lighthouse to capture a baseline on your current PHP version. Record your Time to First Byte (TTFB) in particular, since that is where PHP execution time shows up. After switching PHP on staging, run the same test. You are looking for a drop in TTFB, which reflects faster server-side processing.
Keep in mind the distinction between lab data (a synthetic test run from a fixed location) and field data (real user measurements aggregated by Chrome). Lab data is useful for controlled before-and-after comparisons. Field data tells you how the change lands for actual visitors over time.
Step 4: Switch Production and Watch Logs
Once staging looks clean, switch production PHP through your hosting control panel. The change is usually instantaneous. Monitor your error log closely for the first 24 to 48 hours. If something breaks, switching back is equally fast.
# Tail the WordPress debug log via WP-CLI
wp eval 'echo WP_CONTENT_DIR;' && tail -f $(wp eval 'echo WP_CONTENT_DIR;')/debug.logWhere Caching Fits In
PHP and OPcache handle server-side execution speed. Full-page caching and object caching operate at a different layer and stack on top of those gains.
When LiteSpeed Cache is active on a LiteSpeed server, fully cached pages bypass PHP execution almost entirely for logged-out visitors. OPcache then matters most for logged-in users, cache misses, and dynamic requests that cannot be served from cache. Persistent object caching via Redis or Memcached reduces repetitive database queries. These tools are complementary, not substitutes for each other.
The right order is: get PHP current and OPcache healthy first, then layer caching on top. Caching on a slow PHP foundation still leaves performance on the table.
If you are on a managed host that handles PHP configuration and OPcache tuning as part of the stack, confirm which version is active and verify OPcache is enabled. Do not assume it is configured well just because it is present.
The Takeaway
PHP 8.3 with OPcache is not a cutting-edge experiment. It is a stable, well-supported configuration that delivers faster execution and better security than older versions with zero additional cost. The upgrade path is safe when you test on staging first, check your logs afterward, and keep backups ready.
If your site is still running PHP 7.x or an early 8.x release, this is likely the highest-return performance change you can make today. Run the tests, do the staging check, and flip the switch. The speed is already there waiting.