I set up identical WordPress sites on eight managed hosts and measured what matters: how fast the server responds before anything else happens. Time-to-first-byte tells you if the platform's architecture is working for you or against you.
Every host claims speed. I wanted numbers.
The test environment
Each site ran WordPress 6.5 with the same theme, fifty published posts, and a dozen images in the media library. No page builder, no caching plugin—just the host's native stack. I tested from three geographic locations using a synthetic monitoring tool that hits the homepage, a single post, and the admin dashboard.
The goal was to isolate the host, not the content. Same database seed, same plugin set, same asset footprint. Variance comes from the platform.
Why TTFB matters more than total page load
Total page load includes browser rendering, JavaScript execution, and image decoding. TTFB measures the server alone. If the server takes four hundred milliseconds to send the first byte, you've already lost—no CDN or image optimizer will fix that delay.
In support tickets I handled, slow TTFB usually pointed to one of three things: a struggling database, missing object cache, or overloaded PHP workers. Managed hosts are supposed to eliminate those problems. Some do. Others just wrap shared hosting in a premium label.
What full-page caching actually does
A full-page cache stores the rendered HTML so PHP and MySQL don't run on every request. The first visitor waits for the page to build; the next thousand get a static copy from memory. Cache hit rates above ninety-five percent are normal for public pages.
But logged-in users, search pages, and cart checkpoints can't be cached. That's when the host's backend stack shows itself. Two hosts returned similar cached TTFB but diverged by three hundred milliseconds on dynamic admin pages.
The eight platforms
I tested a mix of infrastructure-as-a-service platforms that include WordPress optimization and traditional managed WordPress hosts. Some use custom control panels; others sit on top of cPanel or Plesk. Pricing ranged from entry-level single-site plans to high-traffic tiers.
I'm not naming them here because this isn't a buying guide. The patterns matter more than the leaderboard.
Pattern one: object cache makes or breaks dynamic performance
Hosts that provision Redis or Memcached for every site delivered admin-dashboard TTFB under two hundred milliseconds. Hosts without persistent object cache hit six hundred milliseconds or worse. WordPress core makes dozens of database queries per admin page load—serializing options, checking transients, loading menus. An object cache collapses that into a handful of cache lookups.
One host offered object cache as an add-on. Base plan TTFB was 580 ms; enabling Redis dropped it to 140 ms. Same hardware, same PHP version. The database didn't change—queries just stopped repeating.
Pattern two: cache purge behavior varies wildly
When you publish a post, the cache has to update. Some hosts purge only the homepage and the new post URL. Others flush the entire cache, forcing every page to rebuild. A full purge on a busy site creates a stampede: fifty requests arrive while the cache is empty, so fifty PHP processes all render the same page simultaneously.
I published a new post on each host and watched TTFB for the next sixty seconds. Three hosts showed a brief spike then recovered within ten seconds. Two hosts stayed slow for almost a minute, likely rebuilding cache on-demand with no queueing.
Pattern three: geographic routing isn't always configured
Managed WordPress hosts often use a CDN for static assets, but the origin server still handles HTML. If the origin sits in a single data center and you test from another continent, you're measuring distance as much as server speed.
Two hosts returned TTFB under 100 ms from the US but over 400 ms from Europe and Asia, even for cached pages. The HTML response was coming from a single location. Other hosts used Anycast or edge caching to serve HTML closer to the visitor, keeping TTFB under 150 ms globally.
So what if the cache is fast but the database still drags?
Query performance under load
I used Query Monitor to log slow queries—anything over fifty milliseconds—while a load testing tool sent twenty concurrent requests to an uncached archive page. The page runs a WordPress loop that fetches twenty posts with metadata, featured images, and category terms.
Hosts with optimized MySQL configurations (query cache, buffer pool size, index usage) completed the query set in under two hundred milliseconds. One host took almost a second, logging repeated queries for post meta that should have been joined or cached. The database server wasn't overloaded; the configuration was default.
Another host used MariaDB with persistent connections and returned queries in half the time of others still on older MySQL versions. The query logic was identical; the database engine made the difference.
PHP version and opcode cache impact
All hosts offered PHP 8.0 or newer, but default settings varied. Hosts with OPcache enabled and configured—enough memory, reasonable revalidation frequency—showed faster script execution. One host's OPcache was too small; I could see cache misses in phpinfo during testing. Scripts had to recompile on every few requests.
PHP-FPM tuning also mattered. Hosts that allocate more workers per site handled concurrent requests without queueing. A few hosts throttled connections aggressively, returning 503 errors under modest load rather than scaling workers.
Admin dashboard and WP-CLI responsiveness
The WordPress admin makes dozens of requests: list tables, autosave AJAX, media library queries. A fast frontend doesn't guarantee a fast backend. I timed common admin actions—saving a post, uploading media, installing a plugin—on each host.
Hosts with admin-specific caching or optimized MySQL indexes responded in under a second for most actions. Others lagged noticeably, especially on plugin pages that query the WordPress.org API and the local database simultaneously.
WP-CLI performance varied too. Some hosts allowed SSH access and had WP-CLI preinstalled; others required a separate tool or didn't support shell access at all. On hosts where I could run wp db query, direct database commands completed in a fraction of the time compared to the same query through the WordPress admin.
What the raw numbers don't show
TTFB and query time are quantifiable. Support quality, staging environments, automatic backups, and uptime aren't captured in a speed test. One host had the slowest cached TTFB but included automatic daily backups, one-click staging, and replied to support tickets in under an hour. Another had the fastest TTFB but charged separately for backups and SSL.
The fastest host isn't always the best host. You're paying for the whole platform, not just the response time.
When managed hosting isn't actually managed
Two hosts in the test group marketed themselves as managed but required manual plugin updates, didn't include staging, and gave no access to error logs without a support ticket. They were shared hosting with WordPress preinstalled. True managed hosting handles updates, monitors performance, and gives you the tools to troubleshoot without waiting on support.
If you're installing a caching plugin yourself, you're not on a managed platform—you're just on an expensive shared plan.
Testing methodology and gotchas
I tested at three times of day across four days to average out transient load. Each TTFB figure represents the median of thirty requests. Outliers—over one second—were investigated separately; most were isolated cache-rebuild events or temporary database locks.
Synthetic tests don't replicate real traffic patterns. A site with mostly logged-in users will see worse performance than my tests suggest. A site with mostly anonymous visitors will see better performance if the cache hit rate is high.
I also tested only the included stack. Some hosts let you swap PHP versions, enable additional extensions, or tune database settings. I used defaults because that's what most users run.
Comparing apples to apples: same-tier pricing
Entry-level plans usually cap CPU, memory, or visitor count. I tested mid-tier plans—enough resources to handle a moderately busy site—so performance differences reflected architecture, not resource starvation. Comparing the cheapest plan on one host to the enterprise tier on another is meaningless.
Some hosts count visits or page views; others count unique sites or storage. Pricing models vary enough that "same tier" is subjective. I normalized by targeting plans that cost between thirty and sixty dollars per month for a single site.
Do I need a managed host if I already use a caching plugin?
Managed hosts provide more than caching. Object cache, optimized database settings, automatic updates, staging environments, and real monitoring are hard to replicate with plugins. If you're comfortable managing a VPS and tuning MySQL yourself, self-hosting can be faster and cheaper. If you'd rather not think about server maintenance, managed hosting is worth the premium.
Can I trust the speed claims on a host's website?
No. Marketing benchmarks usually measure an empty site or test under ideal conditions. Real-world performance depends on your theme, plugin stack, and traffic patterns. Ask for a trial period or money-back window and test your actual site.
Why did some hosts perform worse under load?
Limited PHP workers, undersized database buffers, or missing object cache. A site that serves one request per second performs differently than one handling twenty concurrent requests. If the host overcommits resources or throttles connections, performance degrades quickly under load.
Is TTFB more important than total page load time?
Both matter, but TTFB is entirely within your host's control. Total load time includes third-party scripts, image optimization, and browser rendering—things you can influence separately. If TTFB is high, start there. If TTFB is low but total load is slow, look at frontend optimization.
What to check before switching hosts
Look at your current site's TTFB first. If it's already under two hundred milliseconds for cached pages, switching hosts won't gain much. If it's over five hundred milliseconds, a better platform will make a measurable difference.
Check whether your current host provides object cache, how cache purging works, and whether you have access to logs and performance metrics. If you're troubleshooting blind, a host with better tooling might be worth the move even if raw speed is similar.
Migration matters too. Some hosts include free migration and staging; others charge for it or make you handle it yourself. A slow migration process can mean extended downtime or DNS propagation delays.
Finally, test dynamic pages, not just the homepage. Admin performance, cart pages, and search results reveal more about the host's backend than a cached landing page ever will.