The evidence layer
WordPress hosting benchmarks with the working shown.
Four reports, one fixed cohort, and a public method. We measure the things that decide whether a site feels fast and stays online — then publish the limitations alongside the ranking.
Five regions, 60-day window, two URL states.
Bought at standard rates, configured to the same workload.
Browse, cart, coupon, and checkout under plateau load.
60-day archive last updated 28 October 2026. TTFB is sampled every five minutes.
01 / The reports
Four questions. Four datasets.
Each report is built for a different buying decision. Read the method before you quote a row; the caveats are part of the finding.
Global TTFB tests 2026
Sixty days, five regions, 864,000 requests. The full p50/p75/p95 table, regional splits, and why the fastest origin is not always the fastest site.
WooCommerce load testing
Five hundred concurrent shoppers through a real cart and checkout. p50 to p99, error rates, cache-purge recovery, and the bottlenecks the homepage test misses.
Uptime archive, 60 days
A fixed 60-day archive: 60-second probes, the full incident log, official status links, and a plain-language explanation of what 99.9% actually means for a store or a publisher.
Core Web Vitals by host
A 50-site cohort, grouped by host. LCP, INP, and CLS distributions, the theme effect, and why host attribution is weaker than it looks.
02 / The method
What we do, in plain order.
A fixed cohort, a fixed workload, and published weights. The short version is below; the full protocol lives on the methodology page.
Read the full methodologyScreen for a real product
We start with 22 hosts and remove anything without a credible managed WordPress plan, transparent pricing, or the regional presence to support a five-region test. The final cohort is five.
Build one fixed workload
Same WordPress version, theme, plugin set, product catalogue, and cache policy. Where a host requires its own edge or stack, we document the difference rather than pretending it is neutral.
Measure the distribution
Uptime probes every 60 seconds from Ashburn, Frankfurt, Singapore, Sydney, and São Paulo. TTFB is sampled every five minutes with cached and uncached requests kept separate. We keep p50, p75, and p95.
Publish the limits
Every report names its window, plan, workload, and failure modes. If a result cannot support a claim, we say so. A benchmark without a boundary is marketing.
03 / The uptime archive
Speed is meaningless if the page is down.
The uptime table is a fixed 60-day archive last updated 28 October 2026. Read it alongside the incident log and the official status links, which show current conditions.
Open the uptime archiveCurrent conditions: check the official status pages for Rocket.net, Kinsta, Cloudways, WP Engine, and Pressable.
04 / The limits
What the data can — and cannot — prove.
We would rather lose a dramatic headline than publish a claim the method cannot support. These are the boundaries we apply to every report.
It can prove: relative differences between the tested plans on a fixed workload, in the measured regions, during the stated window. It can expose tail behavior, recovery time, and operational friction that a brochure hides.
It cannot prove: that your site will hit the same number. Your theme, plugins, geography, cache hit ratio, and traffic mix are all variables. A benchmark is a floor and a comparison, not a guarantee.
Data access: summary tables are public. Raw probe logs contain client and account identifiers, so they are not published; a redacted extract can be requested through the contact page.
05 / Read next
Data does not decide.
You do.
The benchmark tells you what happened. The buying guides and playbooks tell you what to do about it.
FAQ
Questions, answered directly.
The details that matter, without the runaround. Prefer the raw method? Start with how we test.
Are these benchmarks real measurements?
They are real measurements from our fixed test cohort. The methods, summary tables, scoring logic, and limitations are public, and the probes run on infrastructure we operate across five regions.
Raw probe logs are not published because they contain client and account identifiers. Researchers and buyers can request a redacted extract through the contact page. Every report states its coverage window and tested plan.
How often are the benchmarks updated?
The TTFB archive and Core Web Vitals cohort are fixed editions, refreshed when a new test window closes. The uptime table is a 60-day archive last updated 28 October 2026; it is not a live feed.
We label every table with its test window so a citation always has a version.
Why do you use p75 instead of average?
Averages hide the slow tail that customers actually feel. p75 means three-quarters of requests were at or below the reported number, which is a better description of a typical experience than a mean pulled around by outliers.
For checkout and other revenue-critical paths, we report p95 and p99 as well. A host with a good average and a bad tail is still a risk.
Can I cite these numbers?
Yes, with attribution to Premium WP Hosting, the report name, the test window, the tested plan, and the metric percentile. Keep the coverage window attached so readers know which edition they are seeing.
The full citation guidance is in the methodology.
Why are only five hosts included?
The cohort is deliberately narrow: hosts with a credible managed WordPress product, a production plan we could buy at standard rates, and enough regional presence to make a five-region test meaningful. Screening 22 hosts down to five is part of the method.
A smaller cohort makes like-for-like configuration easier and keeps the reporting honest.