Benchmarking WordPress Hosts for Speed
Ivan Sp performs a controlled hosting performance test by cloning one identical WordPress site across several providers. Results publish as a follow-up once the current test round completes.
Why Most Hosting Comparisons Are Not Controlled
A typical hosting comparison reviews different sites on different hosts, then compares their load times directly. That comparison conflates two variables at once: the host and the site itself. A faster result might reflect a leaner theme, fewer plugins, or better-optimized images, not the host at all.
A controlled test removes that ambiguity. The only variable that changes between measurements is the host.
WordPress Hosting Test Design
One WordPress site gets cloned identically across multiple hosting providers using a duplicator plugin. Every other variable stays fixed: the same theme version, the same six plugins, the same page and post count, and the same image set. The clone carries 47 pages, 18 posts, and 156 images in every environment.
Two things get measured on each host: setup time, meaning how long it actually takes to get the clone live and working, and performance under the same conditions once it is running.
Why Setup Time Gets Measured Too
A host that is fast once configured and painful to configure correctly still costs real time on every new site launch. Setup time is not a vanity metric here. It reflects a genuine cost most pure speed benchmarks ignore entirely.
What This Benchmark Isolates
Holding the site constant answers a specific question a normal comparison cannot: is a performance problem the host’s fault, or the site’s own configuration. That distinction matters directly for the audit work covered under technical SEO, where a slow site sometimes needs a developer and sometimes needs a different host entirely.
Next Steps for WordPress Hosting
This post documents the method before the results, deliberately. A study publishing conclusions without a stated method invites the reader to trust the numbers on faith. Full results, including which providers were tested and the measured differences, publish as a follow-up once the current round completes.
The WordPress Hosting Test Method, Step by Step
I document the method in full so the design can be checked independently of the results.
- Build one WordPress site with a fixed theme, six fixed plugins, and 47 fixed pages.
- Export that site as a single clone package, so every deployment is byte-identical.
- Select hosts across the tiers a small business would realistically consider.
- Match plan tiers as closely as the hosts permit, and record where matching was impossible.
- Deploy the identical clone to each host, changing nothing between deployments.
- Record setup time from account creation to a working site, on every host.
- Document what optimisation each host applied automatically, since managed hosts differ.
- Measure performance repeatedly across different times of day rather than once.
- Record every figure with its timestamp, so the raw data can be re-examined.
- Publish the host names, the measured figures, and the full method together.
Where the Standard Hosting Comparison Breaks Down
Was the hosting comparison you read measuring the host, or the test site?
- The usual advice
- Compare the benchmark scores published for each host, since the numbers are already available.
- What holds up in practice
- Published hosting benchmarks routinely compare different sites on different plans with different plugin sets. The host is the one variable nobody controlled, which makes the resulting comparison a measurement of the test setup rather than of the hosting.
Picture a comparison table showing load times across eight hosts. The figures are precise and the presentation is confident.
Each row was measured on a different site with a different theme and a different plugin count. The table compares eight configurations rather than eight hosts.
Ivan Sp clones one identical site to every host and changes nothing else. The comparison then measures the only thing that differed.
An uncontrolled comparison produces a confident number about the wrong thing. Businesses migrate hosts on the strength of it.
A migration undertaken on an uncontrolled benchmark spends real money and downtime on a difference that may not exist.
Five Things Commonly Assumed About Hosting Benchmarks
Which of these have you assumed about hosting comparisons?
I write this study against four assumptions that make most comparisons unusable.
| Commonly assumed | What actually holds |
|---|---|
| Published benchmarks compare hosts. | Most compare different sites on different plans with different plugins. The host is rarely the controlled variable. |
| Faster hosting improves rankings directly. | Speed affects user experience and Core Web Vitals. Most sites lose far more to indexing and canonical faults than to hosting. |
| A single load time measurement is meaningful. | One measurement captures one moment. Repeated runs across times of day are what separate a pattern from a fluke. |
| Setup time does not matter. | A host needing hours of configuration carries a real cost that no performance figure captures. |
| Any host can be tested the same way. | Managed hosts apply their own caching and optimisation. Documenting what each applied is part of an honest test. |
This post publishes the method before the results, so anyone can check the design rather than taking the eventual numbers on trust.
A Worked Example: Controlled Against Uncontrolled
Consider two hosting comparisons of the same eight hosts. The comparison below is illustrative, written to show what control changes. No measured results are reported here.
| Property | Typical published comparison | This test design |
|---|---|---|
| Sites compared | Eight different sites | One site, cloned eight times |
| Theme | Different per host | Identical |
| Plugins | Different per host | The same six |
| Page count | Different per host | The same 47 |
| Plan tier | Often different | Matched as closely as the hosts allow |
| Variable actually measured | The whole configuration | The host |
| Setup time recorded | No | Yes |
I hold every row constant except the host. The second-to-last row is the entire point of the exercise.
An uncontrolled hosting benchmark is a race where every runner uses a different track. Somebody finishes first and the result says nothing about the runners.
The final row is the one nobody publishes. A host that takes an afternoon to configure has a cost that no load time figure records.
How This Hosting Benchmark Is Scoped
What You Need to Reproduce This Test
- Time required
- Several days, most of it waiting for repeated measurement windows.
- Access needed
- An account on each host under test.
- Tools required
- A clone or migration plugin, plus a performance measurement tool.
- Skill level
- Comfortable deploying a WordPress site and reading performance metrics.
- Cost
- One month on each host, which is the real expense of a controlled test.
- What can go wrong
- Letting a plan tier, plugin, or theme differ between deployments.
- Expected result
- A comparison where the host is the only thing that differed.
- Current status
- The method has run. Measured results are not yet published.
Hosting Benchmark Tools and Primary Sources
The references below cover the metrics and the tooling this test uses. Each opens in a new tab.
- Core Web Vitals documentation defines the metrics the performance measurements are taken against.
- PageSpeed Insights supplies lab and field measurements for a given URL.
- Search Console Core Web Vitals report reports the field data Google itself uses for a site.
- WordPress developer documentation documents the platform the cloned test site runs on.
Check the Comparison You Are Reading
I suggest four questions for any hosting comparison you find.
- Check whether the same site was deployed to every host, or different sites.
- Check whether the theme and plugin set were identical across the test.
- Check whether plan tiers were matched, and whether mismatches were disclosed.
- Check whether setup time was recorded at all.
A comparison failing the first two questions measured configurations rather than hosts. Most published comparisons fail both.
Common Questions About WordPress Hosting Benchmarks
Why publish the method before the results?
Stating the method first lets a reader judge whether the test design is sound, independent of whatever the numbers turn out to say. It also commits the test to a fixed design before any result could shape it.
How many hosting providers get tested?
The initial round covers three providers, chosen to represent meaningfully different hosting approaches rather than three similar options.
Does this test apply to non-WordPress sites?
The specific test is WordPress-based, since that is the platform this practice implements most often. The controlled-clone principle, isolating the host as the only variable, applies to any platform.