Runtime tuning · Beginner · 10 minutes
Change PHP, Then Measure What It Bought You
You know the newer runtime is quicker, and you have no baseline to prove it or to tell you when something quietly regressed.
The short answer
Take a baseline before you touch the selector. Run curl against the page a dozen times, record the median time to first byte, and write it down — otherwise the upgrade is a belief rather than a result, and you have no way to notice a regression later.
Then switch: PHP is set per domain from the panel, so one site moves while another holds still. Click through the important paths, read the error log, and re-run the same measurement. The first request after a switch is slow because OPcache is cold, which is precisely why one sample proves nothing.
By the HostingFast team · Reviewed 12 August 2026
Beginner
Difficulty grade
5
Stages
Free
Support cost
Proven
Verified on
Ten minutes of work, most of it measurement. It assumes you can open the panel and run a command in a terminal; if the terminal is a problem, a browser-based speed test twice over gets you a rougher version of the same answer.
Rolling back takes as long as rolling forward, which is what makes this cheap to try. The risk lives in abandoned plugins, not in the runtime.
Take the baseline before you touch the selector
curl -o /dev/null -s -w '%{time_starttransfer}\n' against a page that runs real PHP — not a cached static page — a dozen times, and take the median rather than the best or the mean. Server response time is noisy, and one sample tells you about that sample.
Write the number down with the date and the URL. This is the whole difference between reporting that a site feels faster and reporting that median time to first byte fell from one figure to another. It is also how you spot the regression a plugin update causes three weeks later.
Where the version is actually set
The panel's PHP selector assigns a version per domain rather than per account, so a legacy application can stay put while everything else advances. Sites migrated in from elsewhere are frequently several releases behind where they would run happily.
Extensions and INI values are on the same screen and are per version, which is the detail that catches people: switching runtime resets you to that version's extension set, so a module the application needs has to be ticked again rather than inherited.
OPcache, and why the first request lies
PHP caches compiled bytecode in OPcache, and that cache is per version. The moment you switch, it is empty — so the first request compiles everything and looks dreadful. Two or three requests in, you are looking at the real number.
Measure with page caching out of the way as well. A LiteSpeed-cached page returns without running PHP at all, so it reports the same response time on every version and tells you nothing about the runtime change you just made.
Roll back, repair, re-measure
The same dropdown reverses the change in seconds, so a failed attempt costs two minutes rather than an afternoon. That is the argument for trying it today instead of deferring it for a year.
When something breaks, the error log names the file and the function, which nearly always points at one abandoned plugin or an ageing theme. Update or replace that component, switch again, and re-run the measurement — and note that an end-of-life build stops receiving security patches whatever else it appears to be doing for you.

The platform these numbers were measured on
Every measurement here was taken on the stack we operate: the same PHP selector, LiteSpeed in front of it, NVMe underneath. The numbers you get will be your own, from the same tooling.
Order an annual plan and the first year of the domain registration is included at no cost.
- Baseline recorded, not remembered
- Median of a dozen runs, not one
- Cache accounted for in the method
- Engineers on shift at any hour
Why HostingFast
Standard on every plan
Baseline before change
One curl command, several runs, the median written down — otherwise the upgrade is only a belief.
Per domain, not per account
One legacy site can hold still while everything else on the account moves forward.
OPcache accounted for
The first request after a switch is cold, which is exactly why a single sample proves nothing at all.
Extensions checked
The extension list is per version, so a missing module is a tick box rather than a mystery.
Rollback in seconds
The same dropdown reverses the change, which is what makes testing this genuinely cheap.
End-of-life stated plainly
An unsupported build stops receiving security patches, whatever else it appears to be doing well.
Quick Start
From order to online
- 1
Record the baseline
curl the page a dozen times with cache bypassed, take the median time to first byte, and note it with the date and URL. Everything after this is judged against that number.
- 2
Check what the application says it supports
Current WordPress core is fine on modern PHP; the exposure is in old plugins and themes. Skim their tested-up-to notes, or rely on the rollback and find out.
- 3
Switch one domain, then re-tick the extensions
The selector is per domain. Extensions are per version, so confirm the modules the application needs are enabled on the new one.
- 4
Click the critical paths and read the error log
Checkout, login, admin, the forms. Anything incompatible complains within the first couple of minutes, and the log names the component.
- 5
Re-measure and keep the number
Warm the cache with two or three requests first, then take the median again. Store both figures — that pair is your evidence, and your regression alarm.
Built In
Loaded onto every plan
- PHP version set per site from the panel, not per server
- LiteSpeed caching in the server itself, not bolted on by plugin
- NVMe SSD storage on every tier, not just the expensive ones
- SSH, Git and Composer on the developer-focused plans
- Staging environments for testing before anything ships
- Daily backups with restores you trigger yourself from the panel
- Engineers on shift every hour of every day, not a queue that opens at nine
- 99.9% uptime as the target, monitored around the clock
- Migration handled by our engineers at no charge
- Renewal billed at the rate you first signed up at
Frequently Asked
What people ask us most often
How do I prove the version change actually made the site faster?
Median time to first byte on the same URL, measured before and after with page caching bypassed and OPcache warmed by two or three requests. curl -w '%{time_starttransfer}' is enough. Comparing single samples, or measuring a cached page that never touches PHP, is how people conclude an upgrade did nothing.
A required extension is missing on the new version — what now?
Enable it on the new version's extension list, which is a separate list from the old one. Extensions do not carry across a version switch, and a missing module usually surfaces as a class-not-found fatal error naming exactly what it wanted.
Are backups self-service, or do restores go through a ticket?
Yes — every plan gets a daily backup, and the restore runs from your panel in minutes: files, databases or both, at three in the morning with no ticket queue in the way. Keeping an extra copy offsite is still a smart habit, and nothing here prevents it.
Do mailboxes ship with the plan, or are they billed separately?
Yes — every hosting plan includes mailboxes on your own domain, with webmail, IMAP, POP and SMTP plus spam filtering switched on from the start. There is also standalone email hosting for a domain whose website lives somewhere else entirely.
Keep reading
How to Move a Website to a New Domain
A rebrand onto a new hostname with the redirects and the rankings both intact.
How to Migrate Email to a New Host
Destinations, sync, TTL, cut, re-sync — with the counts to prove nothing was lost.
PHP (Glossary)
The runtime your site actually executes on, defined in one screen.
Drupal Hosting
Drupal with Composer, Drush and per-site runtime control on tap.
PHP Hosting
Choose the PHP version per site, on NVMe hardware with LiteSpeed in front.
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.
Run it on a current runtime.
PHP set per site, NVMe on every tier, LiteSpeed in the server itself, and engineers on shift at any hour.
View PHP Hosting plans