How We Test Hosting Speed
We run our own hosting speed lab: a set of identical WordPress sites, one on each host we cover, measured the same way from the same place on a fixed schedule. This page documents the method in full, so any number we publish can be checked against how it was produced.
The short version
For every host in the Speed Index we stand up a bare, identical WordPress install on the host’s entry plan, leave the host’s own caching exactly as it ships, and measure server response time (time to first byte) with repeated requests from one fixed US cloud location. We report the median and the 95th percentile of those requests, plus a separate cold reading. We refresh the published numbers monthly. The value is not any single reading; it is the record that builds up over many runs.
Two kinds of speed data, never mixed
Speed numbers on HostingDive come in two classes. We label every number with its class and we never average one class into the other.
A reading we produced ourselves, in our own lab, on a probe site we control and pay for. This is the data behind the Speed Index. Every host currently in the index is in this class.
Real-world numbers collected by someone else, such as Google’s Chrome User Experience Report. We use this only where we do not run a first-party probe, and we always say so on the spot.
When a comparison includes a host we measure first-party and a host we do not, the two are shown as separate classes with separate labels. We would rather show a gap than paper over one with a borrowed number.
The rig
Each host gets one probe site. The sites are built to be as close to identical as the hosting platforms allow, so that the only thing left to differ is the host itself.
- →Bare WordPress. A clean WordPress install with no added plugins, no imported content, and the default theme. Nothing on the site is doing work except WordPress and the host.
- →The entry plan. We buy the plan most people actually start on, not a high-end tier the host would prefer we test. The same request hits the same path on every site.
- →Cache left as it ships. Whatever caching or CDN the host turns on by default stays on, exactly as a new customer would find it. That as-shipped state is part of what we are measuring, because it is what you would actually get.
- →One fixed vantage. Every site is measured from a single fixed US cloud location, never from an office or home connection, so the network path is stable and the same for all hosts. Absolute milliseconds only mean something when the place you measure from does not move.
- →Same run, back to back. All hosts are measured in one pass, one after another, so a slow network minute hits every host or none.
What we measure, and why it is TTFB
The headline number is time to first byte (TTFB): how long the server takes to start sending the page back after it is asked for. We also record connect time, TLS handshake time, total transfer time, and the size of the returned HTML, and we capture the cache and server headers each host sends so the as-shipped state is on the record.
TTFB is the cleanest hosting signal because the probe sites are identical. When the page being built is the same everywhere, the time the browser spends drawing it is roughly the same everywhere too. What is left, the part that actually changes from host to host, is how fast the server answers. That is the server’s job, and that is what TTFB captures. A full visual-render layer can be added later for a page-paint view; it is not the core hosting signal, so it is not the headline here.
Warm, cold, and how we summarize a run
Within a single run we send the first request as a cold reading, then a series of back-to-back requests as the warm sample. The first request often lands on a cold cache and runs slower; the warm requests reflect the steady state a returning visitor sees. We report both, kept apart.
From the warm requests we report the median (the typical response) and the 95th percentile (a stand-in for the slower end of the spread). We lead with the median rather than the fastest reading because a best-case number is easy to cherry-pick and rarely what you live with. Every requested sample is taken; if a request fails, that is recorded, not quietly dropped.
One run is not a verdict
A single run is a snapshot, and snapshots are noisy. We do not crown a fastest host off one reading. Rank language is earned only once the order holds across repeated runs. What makes the Speed Index worth citing is the history behind it, not any one day’s table.
Hosts in the index today
These are the hosts with a live first-party probe in the lab right now. The roster grows as we add probes; if a host’s plan is cancelled, we keep its collected data and move that host to third-party field data, labeled as such.
| Host | Plan tested | As-shipped stack | Class |
|---|---|---|---|
| SiteGround | StartUp | nginx + SG Optimizer | First-party |
| Hostinger | Business | LiteSpeed + LSCache | First-party |
| Namecheap (EasyWP) | Starter | nginx + EasyWP cache | First-party |
| Cloudways | Vultr 1GB | nginx + Varnish + Breeze | First-party |
| WP Engine | Startup | EverCache + Cloudflare | First-party |
| Bluehost | Basic | Oracle Cloud + WP | First-party |
| Scala Hosting | SPanel Mini | SPanel | First-party |
| Kinsta | Starter | Edge Caching + Cloudflare | First-party |
Current readings for these hosts live on the Speed Index results page, which we refresh monthly.
Independence: measurement does not bend to money
Some of the hosts we measure are affiliate partners, which means HostingDive can earn a commission if you buy through our links. We are stating that plainly because you should weigh it.
Here is the firewall: the probe does not know or care whether a host pays us. Every site is built the same way, measured in the same run, from the same place, and summarized with the same math. A partner host and a non-partner host are treated identically, and a partner that responds slowly will show a slow number. We do not let a host preview its results, and a host cannot buy a better position. If that ever stops being true, this paragraph is the first thing we would have to delete, so it stays.
What we publish, and what we hold back
We publish the method, the metric, the hosts, the plans, the as-shipped stacks, and every number with its date and class. What we do not publish is the operational plumbing: the exact addresses of the probe sites, the precise timing of automated runs, and the raw machine feed. Those are withheld for one reason. A benchmark anyone can identify and target is a benchmark a host could quietly optimize for, and then the numbers would stop meaning anything. Holding back the plumbing is how the numbers stay meaningful.
Found a problem with how we test?
If you think we are measuring the wrong thing, measuring it the wrong way, or missing a host that belongs in the index, tell us. The method changes as the hosting market does, and a good challenge is how it improves.
Contact the team →HostingDive Speed Index. Inaugural dataset published June 2026; numbers refreshed monthly. By the HostingDive Team.