Managed WordPress throughput benchmark
How we benchmark managed WordPress hosting, and how to run the same test yourself: what to measure, how to keep runs comparable across hosts, and the mistakes that make most published hosting benchmarks worthless. Measured results follow in updates as the runs complete.
By Sam Moreton
First-hand testing
Test setup
| Environment | Managed WordPress installs on cloud servers, with identical site content, traffic pattern, load generator and region across hosts; the full environment is recorded alongside each published run |
|---|---|
| Methodology | vv1 |
| Benchmark date | 2026-10-09 |
| Runs | 0 |
| Raw data | evidence/pending/managed-wordpress-throughput |
Limitations
- No measured results yet; the first numbers land in an update once the runs complete and the raw data is committed.
- Vendor-commissioned benchmark figures published by hosts are excluded; only runs we execute ourselves will appear.
- Results describe the region and plan tested until repeats say otherwise.
Hosting benchmarks are mostly worthless, and it helps to say why before claiming ours will be different. The usual test installs an empty WordPress site on each host, fires requests at the homepage from one machine, runs it once, and publishes a winner. An empty WordPress page behind a warm cache is among the easiest things in computing to serve, so every host ties. Add a CDN that nobody turned off for the test and you have measured a network anyone can buy, with the host's own work invisible. This page sets out how we run these tests instead, so the numbers are worth arguing with when they arrive.
What we measure
Time to first byte, split by cache state. Cached TTFB shows how the edge and the server configuration behave. Uncached TTFB, fetched with a cache-busting parameter or on a page excluded from cache, shows PHP and the database doing real work. Publishing only the cached number is the most common way hosting reviews flatter everyone.
Admin responsiveness under load. The WordPress admin is uncached by nature, so it exposes the server's processing capacity in a way public pages hide. We measure admin page loads while the replay traffic runs, because slow admin is the first complaint a real client makes about a host the public tests call fast.
The checkout path. For WooCommerce we time the cart, the checkout request and the order confirmation under load. No page cache helps these requests; they run sessions, database writes and usually mail. It is the most expensive thing a WordPress site does, and the one with revenue attached.
Error rate and latency distribution. For every scenario we record the median and the tail percentiles, because averages hide exactly the requests that lose you customers. Errors are counted separately and named.
How we keep it fair
Same content everywhere. One real site, with a representative plugin set, cloned identically onto each host. Empty installs are banned, and the plugin mix is part of the workload, stated with the results.
Same traffic pattern. A recorded replay of mixed requests, public pages with the share of admin and cart activity a real week contains, instead of a synthetic hammer on one URL.
Cache state declared. Warm-cache tests state how the cache was warmed. Cold-cache tests are labelled and run separately. Silent cache states are how two honest testers reach opposite conclusions about the same host.
Repeat runs. Multiple runs per host, spread across different hours, with the median and the spread reported. A single run is a sample of noise.
Same conditions. One load generator, one region, the same time-of-day windows per host, and paid tiers wherever the trial differs from production resources. Anything that cannot be held equal is listed with the results.
The mistakes that ruin a benchmark
Empty installs, which turn the test into a cache contest. One run, which turns it into a lottery. A CDN left enabled, which turns it into a test of the CDN. One unpublished vantage point, which turns it into a test of geography. Load patterns unlike real traffic, floods of identical requests that the cache absorbs while the database naps. And trial accounts whose resources differ from production, which test the trial. Every one of these appears in published benchmarks from sources that should know better, which is why we wrote the method down first.
How to run it yourself
Take a clone of your real site onto each candidate host; on most managed platforms this is a migration or staging operation you click through. Use any load tool that lets you script a scenario, k6, Locust and the rest all qualify, and record your traffic as a scenario file instead of hammering one URL. Replay it against each host from the same machine and region, several times across different hours, and record TTFB distributions for cached and uncached pages, admin pages, and your checkout flow if you have one. Keep the cache state and the plugin list in your notes. What comes out is a defensible comparison of hosts carrying your actual site, which is the only comparison that predicts your experience.
What lands here next
The method above is fixed and the results are being measured against it. As run sets complete, updates to this page will carry the numbers per host with the environment notes and raw data attached, and nothing will appear here that was measured differently. Until then, read any managed WordPress benchmark you find against this checklist: what was installed, how many runs, whether the CDN was on, and where the load came from. Most published tests fail those four questions before you reach the chart.