The tests that show real performance
You can't trust marketing pages. Every WordPress hosting provider claims blazing speed, but site owners live with the reality: slow admin panels, cache misses after plugin updates, and TTFB that climbs under load. The tests that matter aren't synthetic benchmarks—they're the ones that mirror what your visitors and your workflow actually experience.
I've spent years in hosting support watching site owners migrate between providers, chasing better performance. The pattern is always the same: they run a single speed test, see a good score, then discover the host chokes on their specific plugin stack or that caching breaks after a WooCommerce update. Real evaluation needs six distinct tests, each targeting a different failure mode.
Test one: baseline TTFB under no load
Time to First Byte tells you how long the server takes to start responding. It's not the whole story, but it's the foundation. A WordPress site with no caching, no CDN, and a simple theme should return TTFB under 600ms from a nearby test location. That's your baseline—anything worse means the host is already struggling with basic PHP execution and database queries.
Measure this with a fresh WordPress install. No plugins, default theme, single post. Use cURL from a VPS in the same region as your host's data center:
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://yoursite.com/
Run it ten times and average the results. Outliers matter—if one request takes three seconds while the rest are under 600ms, the host's resource allocation is inconsistent. Shared hosting often shows this pattern because neighbors spike CPU and steal your cycles.
Test two: TTFB with page caching enabled
Now enable the host's built-in page cache or install a caching plugin if they don't provide one. Request the same page ten times. The first request will be slow (cache miss), but subsequent requests should return TTFB under 100ms. That's a cached response being served.
If TTFB stays above 200ms even on cached hits, the cache layer itself is slow. I've seen this on hosts that store cache files on network-attached storage instead of local NVMe or RAM. The cache exists, but fetching it is almost as slow as regenerating the page.
Clear the cache between test runs to verify it's actually rebuilding. Some hosts fake caching—they claim to offer it but the TTFB never improves. Measure before and after; the difference should be dramatic.
Test three: object cache with WooCommerce
Page caching doesn't help logged-in users or dynamic content. Object caching does. Install WooCommerce, add fifty products, and enable persistent object caching (Redis or Memcached). Load the shop page while logged in as an administrator.
Without object cache, that page might take two to four seconds to render because WooCommerce queries the database hundreds of times. With object cache, it should drop to under one second. If it doesn't, the host either doesn't provide a real object cache backend or hasn't configured PHP to use it efficiently.
Check if Redis is actually active:
wp redis info
If the plugin reports a connection but performance doesn't improve, the Redis instance might be under-resourced or located on a separate server with network latency.
Test four: caching behavior after plugin updates
This is where many hosts fail silently. Update a plugin—any plugin—then immediately request your homepage. If TTFB is still under 100ms, the cache survived. If it jumps back to 600ms or higher, the host's cache purge logic is too aggressive.
Some hosts clear the entire page cache whenever any file changes in wp-content. That's lazy engineering. A smart cache only purges pages actually affected by the update. If your cache breaks on every plugin update, your site will be slow every time you maintain it, and automatic background updates will constantly reset performance.
Test this specifically with popular plugins like Yoast SEO or Contact Form 7. Update them, then check TTFB on a page that doesn't use their shortcodes. That page's cache should still be valid.
Test five: plugin compatibility under load
Some hosts impose strict execution limits that break plugins under traffic. Install a form plugin (Gravity Forms, WPForms, anything that processes submissions), then submit ten forms in rapid succession using a script:
for i in {1..10}; do
curl -X POST -d "name=Test&[email protected]" https://yoursite.com/contact/ &
done
wait
Check if all ten submissions succeeded. Look for 503 errors, timeouts, or submissions that vanish without triggering email notifications. Hosts with aggressive rate limiting or low PHP max_execution_time will drop requests under even modest load.
Also check your error logs. If you see "Maximum execution time of 30 seconds exceeded" or "Allowed memory size exhausted," the host's resource limits are too tight for real-world use. Shared hosting often caps these values so low that contact forms time out during spam attacks or backup plugins fail mid-run.
Test six: admin panel responsiveness with plugins active
The WordPress admin panel is a reliable indicator of backend performance. Install fifteen popular plugins (Yoast, Wordfence, WooCommerce, a page builder, a backup plugin, etc.), then measure how long it takes to load /wp-admin/plugins.php.
That page queries the database for every installed plugin, checks for updates, and renders a complex table. On a good host, it loads in under two seconds. On a bad one, it can take ten seconds or hang completely.
Use browser DevTools to measure the time between navigation start and DOM content loaded. If it's above three seconds, you'll spend your entire workday waiting for WordPress to respond. I've seen site owners tolerate slow front-end performance but finally migrate when their admin panel becomes unusable.
What the results tell you
If a host passes test one but fails test two, their caching is misconfigured or nonexistent. You'll get decent performance on cache misses but no benefit from caching, which defeats the purpose of using WordPress caching plugins or host-level cache.
If they pass tests one and two but fail test three, they don't provide real object caching. That's tolerable for simple blogs but a deal-breaker for WooCommerce or membership sites.
Failure on test four means the host prioritizes simplicity over performance. They'd rather purge everything than implement smart cache invalidation. Your site will be fast until you touch anything, then slow until traffic rebuilds the cache.
Test five failures indicate resource limits too strict for production use. The host is overselling capacity, and your site will drop requests during traffic spikes or when background tasks run.
Test six is the workflow test. Failing here means you'll waste hours waiting for the admin panel, even if front-end performance is acceptable.
Why synthetic benchmarks miss the point
Most comparison sites run Pingdom or GTmetrix against a demo site with no plugins and a lightweight theme. That tells you almost nothing. Real WordPress sites have plugins. They have WooCommerce, form handlers, security scanners, backup tools, and page builders. The host that scores perfectly on a synthetic test might collapse under your actual workload.
Synthetic tests also ignore caching behavior. They might measure a fully cached page and declare victory, never checking what happens when cache is invalidated or how the host handles mixed cached and uncached requests.
You need to test the way you actually use WordPress: with your plugins, your theme, your traffic patterns.
Testing from multiple regions
Geography matters more than most site owners realize. A host with data centers only in North America will serve slow TTFB to visitors in Europe or Asia, no matter how fast their servers are. If your audience is global, test from multiple locations.
Use a service that measures from several continents, or spin up small VPS instances in different regions and run cURL tests from each. TTFB should stay under one second globally if the host uses a CDN correctly. If TTFB is 200ms from the US but 1500ms from Australia, the CDN isn't working or the host doesn't have edge locations in that region.
Some hosts advertise global CDN but only cache static assets (images, CSS, JavaScript). HTML pages still come from the origin server, which means international visitors get slow TTFB. Test this by requesting your homepage with cache-busting query parameters and checking the response headers for CDN identifiers.
Retesting after migration
If you're comparing hosts before migrating, run all six tests on your current host first. That gives you a baseline. After migration, run the same tests on the new host with the same plugins and content. The difference tells you whether you actually improved performance or just moved problems around.
I've handled support tickets where site owners migrated to a "faster" host based on marketing claims, then discovered their admin panel was slower, their cache broke on updates, or their forms started timing out. They had no baseline data, so they couldn't prove whether the new host was better or worse.
Document everything: TTFB values, cache hit rates, plugin compatibility results, admin panel load times. Export your WordPress database size and plugin list so you can recreate the exact environment during testing.
Checking resource limits directly
Beyond performance tests, check the host's resource limits. SSH into your server or use a plugin that displays phpinfo():
<?php phpinfo(); ?>
Look for these values: - memory_limit (should be at least 256M, preferably 512M for WooCommerce) - max_execution_time (at least 60 seconds, preferably 120) - upload_max_filesize (at least 64M for media uploads) - post_max_size (at least 64M) - max_input_vars (at least 3000 for page builders)
If memory_limit is 128M and you're running WooCommerce with a page builder, you'll hit out-of-memory errors. If max_execution_time is 30 seconds, backup plugins and import tools will time out.
Some hosts hide these limits behind vague "resource units" or "entry processes." Get the actual numbers before committing.
What to test before committing
Run all six tests during any trial period. Most hosts offer thirty-day refunds; use that window to verify performance with your real site, not a skeleton install. Measure baseline TTFB, enable caching and measure again, install WooCommerce and test object cache, update a plugin and check if cache persists, load-test form submissions, and time your admin panel with a full plugin stack.
If the host fails any test that matters to your workflow, refund and move on. Don't assume you can fix their infrastructure limitations by tweaking your site. You can't optimize your way around inadequate server resources or broken caching logic.