PHP 8.2 vs 8.3 vs 8.4 — real impact on WordPress speed

Ask five hosting blogs which WordPress PHP version to run and you get five answers: 8.1, 8.2, 8.3, 8.4, and one confident outlier saying 8.5. Almost none of them show a number. So here is what we measured across the sites we maintain, on the same box, the same theme, the same plugin set, with only the PHP version swapped. If you just want the WordPress PHP version that makes sense in 2026 without reading the whole thing, the short answer is below.

The short answer

Run 8.3 if you want the safe, broad-compatibility pick. Run 8.4 if your plugins are current and you want the longest support runway. 8.2 still works, but its clock is nearly out: security fixes stop in December 2026. We move most client sites to 8.3 and the well-kept ones straight to 8.4. We have not put a production store on 8.5 yet, because the plugin ecosystem is still catching up and there is no speed reason to rush.

What a faster PHP actually buys you

Here is the part the headlines skip. PHP only runs on the slice of a page that happens before your cache answers. Turn on full-page caching and most of your visitors never touch PHP at all. They get a static HTML file in 150 to 250ms, and the PHP version is irrelevant to them.

So the version matters where the cache cannot help:

• Logged-in sessions, meaning your editors and admins
• WooCommerce cart, checkout, and account pages
• wp-admin itself
• Anything dynamic: REST calls, AJAX, search, form handlers

If your homepage already loads in 200ms from cache, do not expect 8.4 to shave anything off it. There is nothing left to shave. The win shows up in the uncached corners.

The numbers

We ran the same WordPress 6.8 install (Twenty Twenty-Five, roughly 25 active plugins, a small WooCommerce catalog) on a 2 vCPU Hetzner VPS, hammering the uncached account page with a load tool. Only the PHP version changed between runs.

Read those gains honestly. Single digits into low double digits, not the “twice as fast” some upgrade guides imply. The jump from PHP 7.4 to 8.0 was the last big one. Everything since has been steady, modest tuning. JIT, the feature people expect to change this, barely moves a typical WordPress workload. It helps math-heavy code, and WordPress is mostly string and database work.

That does not make the upgrade pointless. A 10% cut on every uncached request is real headroom on a busy store, and it stacks with the security and support benefits, which matter more than the milliseconds anyway.

Where you actually feel it

A shopper browsing your storefront will not notice the difference, because the cache is serving them. The person who feels it is the store owner in wp-admin at 11pm, and the checkout queue during a flash sale when fifty carts hit PHP at once. That is the honest pitch for upgrading. Not a faster website, a faster back office and more checkout headroom under load.

If your pain is a slow public homepage, the PHP version is the wrong lever. Caching and image weight will do far more. We walk through those in our notes on WordPress speed optimization, and the LiteSpeed Cache vs WP Rocket comparison covers the caching side in detail.

Compatibility is the real reason to wait

The thing that stops an upgrade is never PHP itself. It is one plugin.

PHP 8.4 tightened several long-deprecated patterns, like implicitly nullable parameters and some loose type handling, and older or abandoned plugins trip on them. They rarely crash the site outright. More often they flood your debug log with deprecation notices, and on a busy site that log balloons to gigabytes overnight.

Before you switch, check what breaks:

• Turn on WP_DEBUG_LOG and read wp-content/debug.log after clicking through the site
• Install Query Monitor and watch for PHP warnings in the admin bar
• Pay special attention to page builders, old payment gateways, and anything you have not updated in a year

If one plugin complains and the developer has gone quiet, that is your signal to replace it, not to stay on an aging PHP version forever because of it.

The timeline that actually decides this

Speed is the small reason to upgrade. Support is the big one. PHP versions get security patches for a fixed window, and running past it means known holes with no fixes coming.

• 8.1: end of life. If you are here, move now.
• 8.2: security support ends December 2026. Migrate off it this year, not next.
• 8.3: security support through roughly December 2027.
• 8.4: security support through roughly December 2028.

That list, not the benchmark table, is why we push clients forward. An unpatched PHP version is a slow-motion incident. When you check your WordPress PHP version and it starts with 7 or 8.1, treat it as urgent no matter how fast the site feels.

How to switch without breaking anything

On a sane hosting panel this is a twenty-minute job, not a migration. Here is the sequence we use on every site:

1. Clone the site to a staging copy. Most panels do this in a couple of clicks.
2. Bump the PHP version on staging only.
3. Click through everything that matters: admin, a test checkout, contact forms, anything custom.
4. Watch debug.log for deprecation spam and fix or swap the plugin that causes it.
5. Flip production during your quietest hour, and keep the rollback handy. On cPanel it is MultiPHP Manager, on CyberPanel it is the vHost PHP selector, both reversible in one click.

The rollback safety net is the whole point. You are never more than a click from the old version, so there is no reason to sit on an unsupported one out of fear.

What we do with this

We handle PHP upgrades as part of ongoing WordPress support and our maintenance work: staging test, deprecation sweep, the switch itself, and the plugin swap if something old breaks. We will tell you honestly when the gain is a rounding error and when it is worth doing for the support runway alone.

One thing we will not do is tell you to change hosts to change a PHP version. If a provider makes you migrate servers to move from 8.2 to 8.4, that is a reason to leave them, not a project to budget for. On a decent panel it is a selector and a staging test, and it should cost you an afternoon at most. A modern PHP build also encodes images faster, which matters the day you decide whether AVIF is worth the CPU over WebP.