Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

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.

Driving a hosting account through the cPanel dashboard

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. 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. 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. 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. 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. 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

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.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

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