Methodology / v3.2
How we test hosting, and where the method stops.
A benchmark is only useful if you know what it measured. This page documents the baselines, the scoring weights, the data pipeline, and the limits of every claim we publish.
The premise
Hosting is not one product. It is a stack of trade-offs: compute isolation, cache architecture, network topology, support depth, and the willingness to tell a customer “that configuration is wrong for you.”
We test the parts that change the buying decision. Not the parts that make a beautiful landing page: a cached homepage from one city, a hero latency number with no percentile, or a feature list copied from a changelog.
Everything below is designed so another operator could repeat the test, get a different number, and have a productive argument with us about why.
01 / What we measure
The signals that survive contact with traffic.
We separate origin performance from edge performance from task completion. Conflating them is how bad hosting advice happens.
| Signal | What it tells us | How we collect it | What it cannot tell us |
|---|---|---|---|
| TTFB p75 | How quickly the origin and edge begin responding to a cold-ish request. | Synthetic HTTP probes every five minutes from five regions; cached and uncached variants reported separately. | Whether a real browser can render the page quickly. |
| LCP p75 | When the largest visible element becomes available to a visitor. | Field observations from the 50-site cohort, with sites grouped by host, page type, and theme family. | Which specific render-blocking asset delayed an individual page. |
| INP p75 | How responsive the page feels after an interaction. | Field INP observations from the same cohort, covering navigation, add-to-cart, and filter interactions. | Which individual handler or third-party script caused a slow interaction. |
| CLS p75 | Visual stability while the page loads. | Field CLS observations from the same cohort, split by page type and theme family. | Layout shifts introduced after the Sep–Oct 2026 collection window. |
| Uptime | Whether the monitored page responded successfully, consistently. | HTTP status + content checksum from five regions; two consecutive failures define an incident. | Partial degradation that still returns HTTP 200. |
| Woo checkout p95 | How the revenue path behaves under concurrency. | 500 virtual shoppers, mixed browse/add-to-cart/checkout journey, payment gateway mocked. 30-minute run. | Real payment-provider latency and fraud checks. |
| Support quality | Whether a competent operator can get a competent answer. | Standard scenario: a cache configuration error causing intermittent 502s. Chat and ticket transcripts scored for time and resolution. | Every possible escalation path or account tier. |
| Operational friction | The human cost of staging, backups, access, and migrations. | Task-based workflow tests with timed steps and failure notes. | Your team’s specific familiarity with a panel. |
Note: TTFB is measured by synthetic probes. LCP, INP, and CLS are field observations from the 50-site Sep–Oct 2026 cohort. Published reports use the fixed test windows stated on each page. Summary tables are public; raw probe logs are not published because they contain client and account identifiers. A redacted extract can be requested through the contact page.
02 / The baseline
Same stack.
Same data.
Same questions.
Without a fixed baseline, a hosting test is mostly a theme test. We freeze the application layer so the infrastructure is the variable that remains.
The Core Web Vitals cohort is the deliberate exception: it is observational by design, so we control for page type and theme family rather than freezing them.
What we do not do: use vendor demo sites, install “performance” plugins that mask the origin, or compare a cached page on one host with a dynamic page on another.
- WordPress
- 7.1.x, default theme baseline + a fixed block theme
- PHP
- 8.4, OPcache enabled, same memory limit
- Database
- 1.8 GB WooCommerce fixture, 42k orders, 12k products
- Object cache
- Redis where supported; Memcached fallback where not
- CDN
- Provider default, with a separate edge-on / edge-off comparison
- Plugins
- Fixed set: WooCommerce, Stripe (test mode), SEO, forms, cache integration
- Regions
- Ashburn, Frankfurt, Singapore, Sydney, São Paulo
- Probe cadence
- 60 seconds, 24/7, five regions
03 / Scoring
Different intents.
Different weights.
Scores are weighted to the page’s decision. That is deliberate cannibalization avoidance: a speed guide and an enterprise guide should not produce the same order.
| Intent page | Performance | Reliability | Support | Value | Operations | Fit |
|---|---|---|---|---|---|---|
| Premium | 25 | 20 | 20 | 15 | 10 | 10 |
| Managed | 20 | 20 | 25 | 15 | 15 | 5 |
| WooCommerce | 30 | 25 | 15 | 15 | 10 | 5 |
| Enterprise | 15 | 25 | 25 | 5 | 20 | 10 |
| Speed | 55 | 20 | 5 | 10 | 5 | 5 |
| Agencies | 15 | 20 | 20 | 20 | 20 | 5 |
Table note: “Fit” captures whether the plan, contract, and platform model actually match the buyer. A cheap plan that cannot support the workload does not earn a value point.
04 / Data lifecycle
From probe
to published claim.
The pipeline is intentionally boring. Raw probes are retained, aggregations are reproducible, and every report is linked to its window.
Probe and record
Each request stores region, timestamp, status, DNS, connect, TLS, TTFB, bytes, and cache headers. Failed requests are retained.
Remove noise, not inconvenient results
We exclude requests broken by our own configuration, not slow requests. Anomalous windows are reported with the reason.
Percentiles, not poetry
p50, p75, p95, error rates, and regional splits. Host-level summaries never hide a failing region.
Two editors sign the verdict
Scores are checked against the published weights. Claims are narrowed to what the data supports, then checked against the evidence.
05 / Limits
What this lab cannot prove.
Trust is not the absence of caveats. It is knowing exactly where the evidence ends.
Not your production site. A fixed test stack removes variables. Your plugins, custom queries, and traffic mix can change the ranking. Treat scores as a prior, then run your own load test.
Not every plan or region. We test a specific plan in a specific set of locations. A host can be excellent on its flagship plan and weak on the entry tier. We state what was purchased.
Not a security guarantee. We review patch cadence, WAF options, and documented controls, but we do not perform penetration testing of vendor infrastructure.
Not a permanent verdict. Hosting changes fast: a new data center, a price increase, a support reorg. Every report carries a fixed test window, and that window is the point.
06 / Corrections & access
Show the work.
Keep the record.
If we change a verdict, we add a correction note to the page. We do not quietly rewrite history to make an older recommendation look prescient.
Correction log
Every substantive change gets a short description and the reason. Small typos are corrected silently; scores, prices, and verdicts are not.
Data access
The summary tables are published on each report. Raw logs contain client and account identifiers, so they are not public; researchers and buyers can request a redacted extract by contacting us.
Independence review
Commercial partnerships are reviewed annually against the editorial policy. A vendor can request a factual correction; it cannot request a better placement.
FAQ
Questions, answered directly.
The details that matter, without the runaround. Prefer the raw method? Start with how we test.
Do synthetic probes reflect real visitors?
Not exactly. Synthetic probes are controlled, repeatable HTTP requests. They are excellent for comparing origin response time, consistency, and regional routing under identical conditions. They do not capture every browser behaviour, third-party script, or plugin interaction, which is why we pair them with field Core Web Vitals cohorts and WooCommerce task tests.
Why report p75 instead of the average?
The average hides the slow requests customers actually experience. p75 means three-quarters of requests were at or below the reported number. It is strict enough to expose a tail without turning one outlier into a headline. We also publish p50 and p95 in the reports where the distinction matters.
How do you choose the hosts you test?
We screen hosts that actively market managed WordPress, WooCommerce, enterprise, or agency hosting, then shortlist those with credible infrastructure, public pricing, and a real support organization. We exclude hosts we cannot buy access to at standard rates. Current rankings reflect the shortlist for each intent, not every host in the market.
Can hosts pay for a better score?
No. Sponsored placements, paid links, and vendor-supplied benchmark screenshots are not accepted. Affiliate commissions may be earned on some outbound links, but test selection, weights, and verdicts are set before commercial terms are applied. A host cannot review or approve a draft.
How often is data refreshed?
Probes run every 60 seconds from five regions. The published uptime table is a fixed 60-day archive, last updated 28 October 2026, and each host links to its official status page for current conditions. TTFB is sampled every five minutes. Reports are frozen to a stated window and updated as new editions. Pricing is verified manually against current plan pages.