Runtimes, Measured
PHP 8 vs PHP 7 performance — the free upgrade most sites still haven't taken
The single cheapest performance win in hosting is a dropdown in cPanel — and it comes with a security argument attached, because every PHP 7 branch is now years past its last patch.
The short answer
Upgrade — the case is unusually one-sided. Real-world WordPress workloads run double-digit percentages faster on PHP 8 than on 7.4, uncached requests and admin work feel it directly, and the same hardware serves measurably more requests per second. Meanwhile PHP 7.4's security support ended in late 2022, so staying is not a neutral choice: it is running a web-exposed interpreter that no longer receives patches.
The honest footnote is the JIT: PHP 8's headline feature contributes almost nothing to WordPress, which is I/O-bound rather than compute-bound. The genuine gains come from engine-level work — cheaper function calls, faster string and array internals, smarter opcode handling — spread across everything PHP does. Expect meaningful improvement, not miracles, and take it, because it costs a staging test and a dropdown.
By the HostingFast team · Reviewed 25 August 2026
10%+
Typical uncached WordPress gain across the 7-to-8 jump
EOL
Every PHP 7 branch — no security patches since 2022
JIT
Helps compute-bound code; WordPress barely notices
Per-site
cPanel switches versions individually, reversibly
Version upgrades in this industry usually trade effort for marginal gains. The PHP 7-to-8 jump is the exception: measured on real applications rather than synthetic loops, it delivers one of the larger single-step improvements PHP has ever shipped, and it is applied per site from a control panel menu.
Yet a remarkable share of sites still run 7.4 or older, held back by upgrade anxiety that is mostly out of date — the ecosystem's compatibility work is years done. This page separates where PHP 8's speed genuinely comes from, what it means in page-load terms, and the short procedure that makes the upgrade boring.
Where PHP 8's speed actually comes from
Not the JIT. The measured gains on web workloads come from unglamorous engine work across the 8.x line: a leaner function-call convention, faster string and array internals, improved inline caches for method and property lookups, and steady optimiser gains compounding version over version.
These improvements tax nothing and touch everything — every hook WordPress fires, every template a theme renders, every row a plugin processes. That is why the gains show up on real sites and not just microbenchmarks: the engine is simply doing the same work with fewer instructions.
The JIT, in honest terms
The just-in-time compiler turns hot PHP into machine code, and on compute-heavy benchmarks — fractals, number crunching — it produces spectacular multiples. Those are also the workloads a web request never resembles.
A WordPress request spends its life waiting on the database, the filesystem and the network, interleaved with short bursts of PHP. Compiling those bursts harder saves little, which is what every serious WordPress benchmark of the JIT has found. Treat it as a feature for the day you write a computationally heavy job — not as the reason to upgrade, because the engine gains are reason enough.
What the numbers mean at the page level
The improvement lands precisely where sites hurt: uncached requests. Cached pages bypass PHP entirely and gain nothing — a useful reminder of what your cache is worth — while logged-in traffic, admin screens, search, checkout and REST calls all run the interpreter and all get quicker.
The second dividend is capacity. Requests that finish sooner return their PHP worker sooner, so the same worker pool absorbs more concurrent dynamic traffic before queueing begins. On busy WooCommerce sites that headroom is often worth more than the per-request milliseconds.
Upgrading without drama
The procedure: update WordPress core, themes and plugins first, since current versions are PHP-8-ready; clone to staging and switch the clone's PHP version; click through the site with the error log open, paying attention to the oldest and most obscure plugins, which is where fatalities live.
Then switch production from the cPanel PHP selector — per site, effective immediately, reversible from the same menu, which converts the upgrade from a leap into an experiment. On our platform current PHP 8.x versions are standard, staging takes one click, and the selector is yours; the whole exercise fits in an afternoon and pays out on every dynamic request thereafter.
Current runtimes as the default, old ones on request
We keep current PHP 8.x releases available and set sensible defaults, because an interpreter still receiving security patches is part of what 'secure hosting' means. The per-site selector keeps the choice yours — including the choice to test before you leap.
Speed compounds across the stack: an engine that executes fewer instructions, on NVMe that answers reads in microseconds, behind a cache that spares it the anonymous traffic entirely. The PHP version is the layer most sites can upgrade this week.
- Current PHP 8.x versions available on every plan
- Per-site version selection in cPanel, reversible in one click
- Staging environments for the try-before-you-switch test
- OPcache configured as standard, so compiled code stays compiled
Why HostingFast
Standard on every plan
Free speed, honestly sized
Double-digit gains on uncached requests for the cost of an afternoon's testing — the best effort-to-result ratio available to a live site.
A patched interpreter
PHP 7 stopped receiving security fixes in 2022. Moving to 8.x is a security upgrade that happens to make the site faster.
Headroom without hardware
Faster requests free workers sooner, so the same plan absorbs more concurrent dynamic traffic before anything queues.
Quick Start
From order to online
- 1
Update, then clone to staging
Current core, themes and plugins first — compatibility work is long done in maintained code. Stage the site and switch the clone's PHP version.
- 2
Test with the error log open
Click the critical paths — checkout, forms, admin — watching for deprecations and fatals. Suspicion belongs on abandoned plugins, not on WordPress.
- 3
Switch production and measure
Flip the selector, re-run your uncached TTFB benchmark, and keep the before-and-after. Rollback is the same dropdown if anything surprises you.
Built In
Loaded onto every plan
- Current PHP 8.x offered by the host — a platform stuck on old runtimes is telling you something
- Per-site PHP selection, so one legacy site cannot hold the rest hostage
- Staging environment used for the version switch before production sees it
- Error log watched during testing — deprecation notices now beat fatals later
- Uncached TTFB benchmarked before and after, three runs, middle value
- Abandoned plugins replaced, since unmaintained code is the actual upgrade risk
Frequently Asked
What people ask us most often
How much faster is PHP 8 for a real WordPress site?
Published benchmarks and our own platform experience agree on double-digit percentage gains for uncached WordPress requests across the 7.4-to-8.x jump, with each 8.x release adding a little more. Admin work and logged-in browsing feel it most directly. It is a meaningful, measurable step — not a doubling.
Does the JIT compiler speed up WordPress?
Barely. The JIT excels at compute-bound code — tight numeric loops — while a WordPress request is I/O-bound, spending its time on database and filesystem waits between short PHP bursts. The real-world gains come from PHP 8's engine improvements, which apply everywhere. Enable the JIT if you like; just don't expect it to move your TTFB.
Is it safe to upgrade a live site to PHP 8?
With a staging pass, yes — maintained themes and plugins have been PHP-8-compatible for years, and the cPanel selector makes the switch per-site and instantly reversible. The genuine risk concentrates in abandoned plugins, which deserve replacing on security grounds anyway. Test on staging, watch the error log, switch, keep the rollback handy.
Which PHP versions still receive security support?
Every PHP 7 branch is end-of-life — 7.4's security support ended in November 2022 — and early 8.x branches have since retired too, so the safe answer is the newest 8.x your stack supports. Check the official supported-versions table rather than folklore, and treat any host that cannot offer current releases as a red flag.
Will my cached pages get faster after the upgrade?
No — and that is the correct behaviour. Cached pages are served before PHP runs, so no interpreter change can touch them. The upgrade accelerates everything the cache cannot: logged-in traffic, admin, search, checkout, APIs. Together the two cover the whole request spectrum, which is why you want both.
Keep reading
PHP hosting
Current 8.x runtimes, per-site selection and OPcache configured as standard.
WordPress hosting
Where the uncached gains land: admin, logged-in and WooCommerce traffic.
Server cache vs plugin cache
The layer that serves what PHP no longer has to.
Hosting guides
More upgrades ranked by effort against measured return.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Take the afternoon, keep the milliseconds
Staging in one click, the PHP selector in cPanel, current 8.x on every plan — run the before-and-after benchmark yourself inside the 30-day window.
View PHP hosting plans