Disclosure: This guide contains affiliate links to tested hosting services; however, our 2026 benchmarks remain independent and honest, revealing only the best value option
The reliable way to benchmark your web host is to lock the test fixture and environment, separate cached from dynamic paths, repeat enough runs to report distributions, and preserve the raw data. One speed score is not a benchmark.
Step-by-step
- Define the user journey. Choose pages and dynamic actions that matter.
- Clone a fixture. Freeze WordPress, PHP, content, theme, plugins and database.
- Record infrastructure. Plan, region, resources, DNS, CDN, cache, workers and versions.
- Set thresholds. Define p95 latency, errors, throughput and recovery before running.
- Warm deliberately. Separate warm-cache, cold-cache and cache-bypass tests.
- Run baselines. Gather sequential TTFB and controlled browser lab samples.
- Ramp authorized load. Increase gradually while watching application and system metrics.
- Test spike and soak. Measure recovery and long-duration drift.
- Repeat across days/regions. Report median, p75/p95/p99 and failures.
- Publish artifacts. Share scripts, fixture hash, raw output, dates and configuration.
Minimum report
| Area | Include |
|---|---|
| Environment | plan, region, versions, resources |
| Workload | paths, cache ratio, rate, duration |
| Latency | median, p75, p95, p99 |
| Reliability | errors, timeouts, recovery |
| Browser | LCP, INP/field data, CLS, TBT/lab |
| Evidence | scripts, raw files and run dates |
Reproducible benchmark design
Use the same WordPress version, PHP version, theme, plugins, database, content, image files and cache rules. Clone one sanitized fixture rather than building sites by hand. Match region, vCPU/RAM class and price as closely as products permit. Record plan, data center, DNS, CDN, PHP workers, storage, software versions and every optimization.
Test at least four paths: cacheable home page, cacheable article, uncached search or query, and an authenticated/dynamic action such as WooCommerce cart. A host with excellent edge-cache TTFB may still queue PHP workers on dynamic requests. Do not average cached and uncached data into one meaningless score.
Warm caches deliberately, then run cold-cache tests separately. Use a neutral load generator in a known region, synchronized clock and stable network. Repeat on multiple days. Publish median and p75/p95/p99 latency, throughput, error rate and sample count—not only the fastest request.
Never load-test a provider or production site without authorization. Start small, define abort thresholds and coordinate high-load tests. A denial-of-service incident is not a benchmark.
What to measure
DNS, connection, TLS and server processing contribute to Time to First Byte. Browser TTFB also includes redirects and network latency. Chrome guidance uses 800 ms as a recommended TTFB reference, while an older Lighthouse server-response audit used a stricter 600 ms server threshold. Measure origin and CDN separately.
For pages, capture LCP, INP and CLS from real users where possible. Core Web Vitals are assessed at the 75th percentile of page visits. Lab Lighthouse runs help diagnose, but one score on one laptop is not field performance. Also record FCP, TBT, transferred bytes, request count and long tasks.
For load, define a traffic model rather than “100 users.” Use arrival rate, request mix, think time, session duration and cache ratio from analytics. Track CPU, memory, load average, PHP workers, database latency, cache hit rate, disk I/O and throttling during the run.
A practical test matrix
| Test | Suggested run | Report |
|---|---|---|
| Baseline TTFB | 30–100 sequential warm requests | median, p75, p95, failures |
| Geographic | 3+ regions through CDN and origin | regional median/p95 |
| Ramp | low to expected peak over 10–20 min | p95, throughput, errors, saturation |
| Spike | short authorized burst | recovery time and errors |
| Soak | expected load for 1–4 hours | drift, leaks, throttling |
| Browser lab | 5+ controlled mobile runs/page | median LCP/TBT/CLS |
Set pass/fail thresholds before running. Example engineering targets might be error rate below 1%, p95 cached TTFB under 800 ms from the chosen test region, and no upward latency drift during soak. These are project targets, not universal guarantees.
Avoid common benchmark fraud
Do not call one curl request a speed test, compare different themes, leave one CDN on, test one host from its nearest city and another cross-ocean, or publish synthetic visitors without the request script. Do not label a vendor uptime percentage as measured uptime.
Disclose affiliate relationships, sponsored accounts, free plans and vendor tuning. Preserve scripts, fixture hash, raw CSV/JSON, dates and screenshots. A result without raw evidence is an observation, not a reproducible benchmark.
Virtual machines can vary across allocations. Reprovision or repeat on more than one instance when comparing cloud providers. Shared hosting includes neighbor and scheduler effects; longer observation reveals them better than a five-minute run.
Uptime monitoring correctly
Probe from multiple independent regions every 30–60 seconds and require confirmation before declaring downtime. Record DNS, TLS, HTTP status, content check and latency. A 200 response containing a database-error page is not uptime.
Separate planned maintenance, provider network failure, DNS failure, CDN failure and application failure, but report user-visible availability. Calculate availability from monitored minutes and include the window. One month is too short to validate a yearly SLA.
Keep an external status page and alert path that do not depend on the monitored host. Review SLA definitions: service credits often require a claim and exclude maintenance, attacks or customer configuration.
Optimization order
Fix correctness first: errors, redirect chains, TLS, cache headers and broken jobs. Then add full-page cache for anonymous pages, persistent object cache for repeated database objects when justified, optimized images, fewer third-party scripts, modern PHP, OPcache and database/index cleanup.
A CDN helps static assets globally and, when configured, cacheable HTML. It cannot fix slow uncached PHP or database queries. Object caching can reduce database work but adds network/memory overhead and invalidation complexity; measure before and after.
More RAM helps only when memory pressure, swapping, cache eviction or worker capacity is the bottleneck. More CPU helps compute or concurrency; neither removes slow queries or external APIs.
Migration validation
Benchmark before migrating, clone the site, match software versions, test via hosts-file override and compare functionality. Lower DNS TTL, synchronize late database changes, switch records, issue SSL and retain the old environment during verification.
Compare the same cache state after migration. Monitor 404/500 errors, checkout, forms, cron, search, email, robots, canonical tags and analytics. A faster homepage with a broken cart is a failed migration.
Common mistakes
Do not test unauthorized infrastructure, use only an average, mix cache states, change plugins mid-comparison, ignore errors, or optimize one host privately. Do not claim uptime from a short ping window.
Frequently asked questions
Can I use PageSpeed Insights alone?
No. Combine field data, controlled lab runs, origin timing and server/load metrics.
How many virtual users?
Derive arrival rate from real traffic and business forecasts. “100 users” without request behavior is undefined.
Should I disable the CDN?
Run both origin and normal production stack. Users experience the CDN; engineering needs origin visibility.
What if results vary?
Report the distribution, investigate routing and resource saturation, and repeat. Variance is a result, not noise to hide.