If you have shopped for hosting recently you have seen a chart with four bars, three of them grey, one of them the vendor's, and a number like '3.2× faster' hovering above it. The methodology is never published. When it is, it usually turns out to be a fully cached static HTML file served from a warm edge node, measured from a machine in the same city as the datacenter.
That benchmark measures almost nothing you care about. It cannot distinguish a well-run platform from a badly oversold one, because a cached static file is fast on both. The number that separates them is time to first byte on an uncached, database-backed request, measured repeatedly, at the 95th percentile, at the times of day when the machine is busiest.
Why TTFB is hard to fake
TTFB on a cold request is the sum of the things a host cannot fix with a CDN: how long the request waits for a PHP worker, how long the query waits for a disk, and how long the disk waits for the forty other tenants on the same node. Every one of those is a capacity decision made by the host months before you signed up.
- Worker wait time exposes how many PHP-FPM children per core the host provisions.
- Disk queue depth exposes whether NVMe is actually NVMe, or a SATA array behind a caching layer.
- Variance between p50 and p95 exposes noisy-neighbour contention better than any average.
- Cold-cache repeatability exposes whether the first measurement was a fluke.
How we measure ours
We run a WordPress install with a 4,200-post database, no page caching, no object caching, and a theme that issues eleven queries per request. It is deliberately unoptimised, because your site probably is too. Every fifteen minutes, from fourteen regions, we request an uncached permalink and record the full timing breakdown.
$ curl -w '@fmt' -o /dev/null -s https://bench.srvdaddy.net/post/3181dns_lookup 0.009stcp_connect 0.021stls_handshake 0.038sttfb 0.113s <- the number that matterstotal 0.147s113 ms on a cold, eleven-query WordPress request. Our published figure is the p95 across all fourteen regions over the trailing 30 days, which is currently 141 ms. We publish p95 rather than median because the median hides exactly the contention you are trying to detect.
What to do with this when you are shopping
- Ask the host for p95 TTFB on an uncached dynamic request. If they answer with a Lighthouse score, they have not measured it.
- Ask what the measurement interval is. Hourly is fine. 'When we last checked' is not.
- Ask for the ratio of p95 to p50. Under 2× is a well-provisioned node. Over 4× means somebody else's traffic is your problem.
- Test it yourself during the trial window, at 9pm local time in the busiest region, not at 4am.
“The fastest way to make a hosting benchmark look good is to stop measuring the part that is slow.”
We would rather publish a number that is beatable and true than one that is impressive and meaningless. If you beat 141 ms elsewhere on the same test, we would genuinely like to see the methodology — send it to us and we will publish it.