Comparing WordPress hosting environments sounds like it should be simple: install the same site on two hosts, run a speed test on each, and see which number is bigger. In practice, that approach produces a number, not an answer, because so many variables outside the host itself can swing the result. This guide covers how to design a comparison that’s actually fair, what it can and can’t prove, and how to avoid publishing or acting on a conclusion your own data doesn’t really support. It’s a companion to our guide on recognizing whether your current hosting is actually the bottleneck, which covers a different question: diagnosing one existing host, rather than comparing candidates.
What a hosting benchmark can and cannot prove
A well-designed benchmark can tell you how two specific environments handle a defined workload under controlled conditions. It cannot tell you which host is universally faster, since a different theme, traffic pattern, or geographic audience can change the outcome entirely. Treat any result as evidence about the exact conditions tested, not a general verdict.
Defining the website and workload being tested
Before running anything, define precisely what you’re testing: a specific page type, a specific content volume, and a specific expected traffic pattern. “WordPress performance” isn’t one thing; a lightweight blog and a WooCommerce store with thousands of products stress completely different parts of a hosting environment. If you’re comparing across hosting categories rather than specific providers, our guide to choosing between shared, VPS, cloud, and managed hosting is useful background before you design the test itself.
Using identical WordPress versions
Run the same WordPress core version on every environment being compared. A version difference can introduce unrelated performance changes that have nothing to do with the hosting itself.
Matching themes, plugins, content, and database size
Install the identical theme and plugin set, with identical versions, on every environment. Import comparable content volume and database size, since a near-empty test installation behaves very differently from a mature site with years of accumulated content and database growth.
Matching PHP versions and configuration where practical
Use the same PHP version across environments wherever the hosts support it. Where a host enforces a specific PHP configuration you can’t change, note that as a genuine difference between the environments rather than something to work around silently.
Variables outside the application layer
Geographic server location
A server physically closer to your test location, or your actual audience, will generally show a faster response purely due to network distance. Match server regions where possible, or explicitly account for location as a variable in your results rather than ignoring it.
DNS and CDN variables
If a CDN sits in front of one environment and not the other, you’re no longer comparing hosting; you’re comparing hosting-plus-CDN against hosting-alone. Either test both with the same CDN configuration, or both without one, and be explicit about which comparison you’re actually running.
Cache state and request type
Cold-cache versus warm-cache testing
A cold-cache test reflects a first-time visitor or a freshly cleared cache; a warm-cache test reflects a repeat visitor benefiting from cached content. These can produce very different results on the same host, so test both states deliberately and report which one a given result reflects.
Cached versus uncached requests
A cached response mostly measures your caching configuration, not raw hosting capability. To genuinely compare hosting environments, include uncached requests specifically, since that’s where PHP execution and database performance, the parts hosting most directly controls, actually show up.
Public pages versus logged-in or dynamic requests
Public, cacheable pages and logged-in or otherwise dynamic pages (a cart, a dashboard, a search results page) exercise completely different parts of the stack. Test both categories separately rather than assuming one represents the other.
What to actually measure
Homepage, article, archive, and dynamic-page testing
Test more than one page type. A homepage, a typical article or product page, a category or archive page, and at least one genuinely dynamic page each stress the environment differently, and a host that performs well on one type won’t necessarily perform equally well on another.
Time to First Byte
TTFB reflects how quickly the server begins responding, capturing server processing and network latency combined. It’s a useful, hosting-relevant signal, but it has real limitations: it doesn’t tell you what happens after the first byte arrives, and it can be affected by factors like a CDN or proxy sitting in front of the origin.
Full-page loading metrics and Lighthouse laboratory data
Full page-load metrics and Lighthouse lab data (Largest Contentful Paint, Total Blocking Time, and similar) capture more of the end-to-end experience than TTFB alone, but remember these are simulated, single-run measurements under fixed conditions, not a guarantee of real-user experience.
Real-user field data limitations
Real-user field data (from the Chrome UX Report) reflects actual visitor experience over time, but it requires meaningful traffic to a specific URL to exist at all, and it can’t be generated on demand for a fresh test environment. For a controlled hosting comparison, lab-based testing is generally your practical option, with field data as a longer-term signal once a site has genuinely been live and receiving traffic on each environment.
Server-side signals worth checking
Beyond page-load metrics, several server-side factors directly affect what a host can deliver.
Server response consistency
A single fast response doesn’t tell you much on its own; consistency across repeated requests matters more. A host that’s fast once and slow the next time under identical conditions is telling you something a single test would miss entirely.
PHP execution time and database-query performance
Where you have access to server-level or application-level diagnostics, PHP execution time and database-query timing isolate application-layer performance from network and caching effects, giving a clearer picture of raw processing capability.
Object caching and full-page caching availability
Check whether persistent object caching (Redis or Memcached) is available and whether it’s actually configured and active, since this materially affects database-heavy workloads and is sometimes available but not enabled by default.
PHP workers, concurrency limits, CPU throttling, and memory limits
These resource limits determine how a host behaves under concurrent load, not just single-request speed. A host that looks identical to another under a single test can behave very differently once multiple simultaneous requests compete for the same limited resources. Our guide to how hosting and PHP version set your server’s performance floor explains these concepts in more depth.
Disk and storage performance, and external HTTP requests
Storage I/O speed affects file-heavy operations, and any external HTTP requests your site makes (API calls, license checks, remote assets) add latency that’s only partly related to the host itself, since the remote service’s own response time also factors in.
Scheduled tasks and cron
WordPress’s own scheduled tasks, and any server-level cron jobs, can add periodic overhead. Be aware of what’s scheduled during a test window, since a benchmark run coinciding with a heavy scheduled task produces a misleading result for that specific run.
Testing methodology
Testing from multiple locations
Where practical, test from more than one geographic location, since a result from a single test location conflates the host’s actual performance with the network distance from that specific point.
Running multiple comparable test rounds
Run each test multiple times rather than once. A single result can be affected by transient network conditions or momentary server load unrelated to the host’s typical behavior.
Median versus best result
Report the median result across your test rounds, not the single best one. The best result flatters whichever environment happened to have a lucky run; the median reflects typical behavior more honestly.
Recording variability and outliers
Note the spread between your fastest and slowest results for each environment, not just the average. A host with a tight, consistent range is telling you something different than one with a wide, unpredictable range, even if their medians are similar.
Recording comparable Mobile and Desktop snapshots
For the page-level metrics in your comparison, you can run a WordPress speed test on Mobile and Desktop for each environment under matching conditions, recording lab metrics and, where available, field data as part of your comparison. This is genuinely useful for capturing consistent, repeatable snapshots, but it’s worth being explicit about what it does and doesn’t cover: a public page-speed tool like this does not replace server-level monitoring, application profiling, or a responsible, deliberately designed load test, each of which measures a different layer of what “hosting performance” actually means.
Load testing versus ordinary page-speed testing
Ordinary page-speed testing measures how one request performs. Load testing measures how a system behaves under many simultaneous requests, which is a fundamentally different question and requires different tools entirely.
Permission and responsible load-testing limits
Never run load testing against a hosting environment, your own or anyone else’s, without explicit permission from the host, since aggressive concurrent request volume can resemble an attack, violate a host’s terms of service, or genuinely degrade service for other customers on shared infrastructure. If load testing is part of your evaluation, coordinate with the host in advance and follow their documented guidelines.
Site-type-specific and operational considerations
WooCommerce and membership-site considerations
Stores and membership sites have more dynamic, uncacheable activity than a typical content site, so weight your test workload accordingly rather than relying primarily on static-page results if that’s not representative of the site you’re actually planning to host.
Support response and operational factors
Raw performance numbers don’t capture support responsiveness or how a host handles an incident. These matter for a real hosting decision and deserve separate evaluation alongside your performance data.
Pricing and renewal costs as a separate factor
Keep pricing and renewal-cost comparison explicitly separate from your technical performance findings. Conflating the two can lead to a conclusion that a host is “better” when it’s actually just cheaper, or the reverse.
Disclosure requirements
If you publish a hosting comparison publicly, disclose your testing method, the specific conditions tested, and any commercial relationship with any host mentioned, so readers can weigh your results appropriately.
A repeatable benchmark worksheet
This pairs well with the baseline discipline in how to measure WordPress speed before making any changes, applied here across multiple environments instead of a single site.
- Define the workload: page types, content volume, database size, expected traffic pattern.
- Match WordPress version, theme, plugins, and PHP version across environments.
- Record server location and CDN configuration for each environment.
- Test cold-cache and warm-cache states separately.
- Test cached and uncached requests separately.
- Test public and logged-in/dynamic pages separately.
- Record TTFB, full-page lab metrics, and where available, field data.
- Run multiple test rounds from more than one location where practical.
- Report the median result and the variability range, not just one number.
- Keep performance findings and pricing/support findings clearly separate.
A hosting-comparison checklist
- Have you matched WordPress version, theme, plugins, and content volume across environments?
- Have you accounted for server location and CDN configuration as explicit variables?
- Have you tested both cached and uncached requests?
- Have you tested more than one page type, including a dynamic one?
- Have you run multiple test rounds and reported the median, not just the best result?
- Have you avoided load testing without explicit host permission?
- Have you kept performance findings separate from pricing and support findings?
- If publishing results, have you disclosed your method and any commercial relationship?
Key Takeaways
- A benchmark proves how two specific environments handled a specific, controlled workload, not which host is universally faster.
- Match WordPress version, theme, plugins, content volume, and PHP version before comparing, and treat server location and CDN presence as explicit variables.
- Test cached and uncached, and public and dynamic, requests separately, since they exercise different parts of the stack.
- Report the median across multiple test rounds, and the variability between them, rather than a single best result.
- Never load-test a hosting environment without explicit permission from the host.
Frequently Asked Questions
Can I trust a single PageSpeed Insights result to compare two hosts?
Not on its own. A single test reflects one moment under one set of conditions. A fair comparison needs multiple test rounds, matched configurations, and separate cached/uncached and public/dynamic testing.
Is it safe to load-test a host to see how it handles traffic spikes?
Only with the host’s explicit permission. Unauthorized load testing can resemble an attack, violate terms of service, and affect other customers on shared infrastructure.
Why did my two hosting environments show different results even with the same WordPress setup?
Check for differences in server location, CDN configuration, cache state during testing, PHP version, and whether object caching was actually enabled, since any of these can produce a real difference unrelated to the host’s underlying capability.
Should I test with a freshly installed WordPress site or a full copy of my real site?
A copy matching your real site’s content volume, database size, and plugin set gives a more representative result. A near-empty test installation can behave quite differently from a mature, content-heavy site.
How many times should I run each test?
Enough to see a stable pattern rather than a single data point, and ideally from more than one location. Report the median result and note the spread between your fastest and slowest runs.
Conclusion
A genuinely useful hosting comparison comes from controlling as many variables as practical, testing more than one condition and page type, and reporting a realistic range rather than a single flattering number. Treat any result as evidence about the exact setup you tested, be explicit about what you didn’t control for, and keep performance findings separate from pricing, support, and other operational factors that matter just as much to an actual hosting decision.
