I run hundreds of WordPress sites across different hosts. The question I get most from clients: which host is actually fastest? Marketing pages promise sub-second load times, but real-world performance under load tells a different story.
I built identical WordPress sites on eight popular hosts and ran them through the same traffic patterns for three weeks. Same theme, same plugins, same content. The only variable was the hosting infrastructure itself.
The test methodology
Each site ran WordPress 6.5 with the Twenty Twenty-Four theme and a standard plugin stack: Yoast SEO, WP Super Cache, Contact Form 7, and Wordfence. No page builders, no WooCommerce — a typical business site with about twenty pages and fifty images.
I measured three things:
- Time to first byte (TTFB) from five geographic locations every fifteen minutes
- Full page load time including all assets
- Response times under load using gradual traffic ramps from fifty to five hundred concurrent visitors
All sites used the same PHP version (8.2), MySQL 8.0 where available, and enabled object caching. I disabled CDNs to isolate server performance.
Traffic patterns
Real traffic isn't constant. I simulated three patterns: steady baseline traffic (ten requests per minute), morning spikes (two hundred concurrent visitors for thirty minutes), and slow ramps that increased load by twenty percent every ten minutes until response times degraded.
The slow ramp test revealed breaking points fast. Some hosts sailed past three hundred concurrent visitors. Others started queuing requests at one-fifty.
Shared hosting results
I tested three shared hosting plans because that's where most WordPress sites start.
Shared hosting TTFB ranged from 280ms to 950ms under baseline load. The fastest shared host kept TTFB under 400ms even during morning spikes. The slowest regularly spiked above a second when neighbors on the same server got busy.
Resource throttling matters more than you think
Every shared host throttles CPU and I/O. The question is how aggressively.
One host kept my test site's CPU time under twenty percent even during load tests. Another throttled it down to five percent the moment I hit one hundred concurrent visitors, and response times ballooned to eight seconds. The site stayed online but was unusable.
Check your host's resource limits in cPanel or your control panel. If you're hitting CPU or I/O limits regularly, shared hosting won't cut it regardless of how the plan is marketed.
Managed WordPress hosting performance
Managed WordPress hosts cost more but promise better performance through WordPress-specific caching and optimization.
Two managed hosts in my test delivered consistently fast TTFB (under 200ms) and handled traffic spikes without breaking a sweat. Their server-level caching meant most requests never hit PHP at all.
The caching advantage
Managed hosts typically run Varnish or NGINX FastCGI cache in front of WordPress. When configured correctly, ninety-plus percent of requests serve from cache in under 100ms.
One managed host served cached pages in 45ms on average. Uncached requests (logged-in users, POST requests) took 320ms — still respectable. Another managed host showed similar cached performance but uncached requests regularly exceeded 800ms, suggesting CPU or database bottlenecks.
If you're paying for managed hosting, verify that caching is actually working. Hit your homepage twice and compare the response headers:
curl -I https://yoursite.com | grep -i cache
You should see cache status headers. If every request shows a miss, something's misconfigured.
VPS and cloud hosting patterns
I tested three VPS and cloud hosting providers with two vCPUs and 4GB RAM each. Performance varied wildly despite identical specs on paper.
CPU performance isn't equal
Virtual CPUs share physical cores. Some providers oversubscribe heavily; others guarantee dedicated CPU time.
The fastest VPS consistently handled four hundred concurrent visitors with TTFB under 300ms. The slowest struggled past two hundred, with TTFB spiking to three seconds and PHP-FPM queues backing up.
I ran a quick CPU benchmark on each:
sysbench cpu --threads=2 --time=30 run
The results correlated perfectly with WordPress performance. The host with the highest sysbench score handled load best. If you're on a VPS, run this test. If your score is thirty percent lower than other providers with similar specs, you're on oversubscribed hardware.
Disk I/O killed one host completely
One cloud provider used network-attached storage that couldn't keep up during load tests. MySQL queries that should take ten milliseconds took two hundred. The site ground to a halt at one-fifty concurrent visitors even though CPU was under fifty percent.
Check disk performance:
dd if=/dev/zero of=testfile bs=1M count=1024 conv=fdatasync
You want at least 200 MB/s write speed. Anything under 100 MB/s will bottleneck WordPress during traffic spikes when the database writes cache entries, logs, and session data.
Database performance differences
WordPress hammers the database. Poorly tuned MySQL can be the limiting factor even when CPU and RAM are fine.
Query cache and buffer pool sizing
Two hosts in my test ran default MySQL configs. They struggled under load. Three others had optimized innodb_buffer_pool_size and proper query cache settings — night and day difference.
On a 4GB VPS, innodb_buffer_pool_size should be 2-3GB if WordPress is the only application. Check your current setting:
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
If it's 128MB, you're leaving performance on the table. Most managed hosts tune this automatically. On a VPS, you'll need to edit /etc/my.cnf.
Connection limits matter during spikes
One host had MySQL max_connections set to fifty. During load tests, WordPress couldn't get database connections and served errors. Visitors saw "Error establishing database connection" even though the server had plenty of resources.
That's a config problem, not a resource problem. Check your limit:
mysql -e "SHOW VARIABLES LIKE 'max_connections';"
For WordPress, one hundred connections is reasonable for most sites. More for high-traffic or multisite installs.
PHP-FPM configuration impact
PHP-FPM worker processes handle WordPress requests. Too few workers and requests queue during traffic spikes. Too many and you waste RAM.
The worker calculation
Each PHP-FPM worker uses 30-60MB of RAM depending on your plugins. On a 4GB VPS with 3GB available for PHP, you can run fifty to ninety workers.
I tested three PM (process manager) strategies: static, dynamic, and ondemand. Static performed best under load because workers were always ready. Dynamic saved RAM during quiet periods but took longer to spawn workers during spikes.
Check your current pool config in /etc/php-fpm.d/www.conf or your host's equivalent:
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
If pm.max_children is set to ten or twenty, you'll hit a ceiling fast. For a 4GB VPS, forty to fifty max children is reasonable.
One host had workers timing out
PHP-FPM has a request_terminate_timeout setting. One provider set it to thirty seconds. During load tests, long-running requests (image processing, plugin updates) got killed, leaving the site in a broken state.
I prefer sixty seconds minimum. For sites with background processing, ninety or more. Zero means no timeout, but that's risky — a runaway script can lock up a worker forever.
Geographic performance variance
TTFB from a server in New York looks different than TTFB from Tokyo. I measured from five locations: US East, US West, London, Frankfurt, and Singapore.
Hosts with multiple data centers let you choose server location. Sites targeting US visitors should be in the US. European visitors need European servers. Physics matters — light through fiber only goes so fast.
One host with US-only servers showed 420ms TTFB from Tokyo. Another with an Asia-Pacific data center showed 180ms. For visitors in that region, the second site felt twice as fast even though both hosts had similar performance within the US.
The hosts that handled load best
Two patterns emerged from the testing:
-
Managed WordPress hosts with good infrastructure handled spikes gracefully. Server-level caching absorbed most traffic, and optimized PHP/MySQL configs handled uncached requests efficiently.
-
Well-configured VPS instances with dedicated CPU, fast storage, and tuned MySQL/PHP-FPM matched or beat managed hosts once I optimized them — but required more hands-on work.
Shared hosting was inconsistent. The best shared plan performed comparably to lower-tier managed hosting during normal traffic, but couldn't handle sustained load. The worst shared plans struggled to keep TTFB under a second.
What broke first during load tests
Three failure modes showed up:
- CPU throttling on shared hosting — response times climbed linearly as the host throttled CPU allocation
- PHP-FPM worker exhaustion — requests queued waiting for available workers
- MySQL connection limits — WordPress couldn't connect to the database during spikes
The hosts that performed best avoided all three by provisioning adequate resources and configuring limits appropriately.
What to check on your current host
Don't switch hosts based on benchmarks alone. Test your current setup first.
Run a baseline load test
Use a tool like ab (Apache Bench) or siege to simulate concurrent traffic:
ab -n 1000 -c 50 https://yoursite.com/
That's one thousand requests with fifty concurrent connections. Watch your server metrics in cPanel or your monitoring tool. If CPU, RAM, or I/O max out, you know the bottleneck.
Check resource usage patterns
Log into your control panel and review resource usage over the past week. Are you hitting CPU or memory limits regularly? What times of day?
If you're on shared hosting and constantly bumping against limits, you've outgrown the plan. If you're at twenty percent resource usage even during peak traffic, you're probably fine where you are.
Monitor TTFB from multiple locations
Use a monitoring service or set up simple uptime checks from different geographic regions. TTFB variance tells you whether your host's network and routing are solid or if certain regions see degraded performance.
Finding your performance baseline
Before you switch hosts chasing speed gains, measure your current site properly. Install a monitoring plugin or service that tracks TTFB, full page load time, and uptime. Let it collect data for at least a week.
Then run a load test during a low-traffic window to see how your host handles spikes. If everything holds up fine, your host is probably adequate. If response times climb past two seconds under moderate load, you have a clear reason to move.
The fastest host on paper won't help if your theme is bloated or your database has fifty thousand post revisions. Fix obvious WordPress performance issues first — enable object caching, optimize images, clean up your database. Then assess whether hosting is still the bottleneck.