Time-to-first-byte matters more than most site owners realize. It's the delay between a browser request and the first byte of the server's response—before HTML renders, before CSS loads, before anything visible happens. On an uncached page hit, TTFB reveals how fast your host can actually generate WordPress output.
I tested eight managed WordPress hosts in early 2026, measuring uncached TTFB from three geographic locations. Four providers consistently delivered under 200ms. The rest sat between 250ms and 450ms, which adds up fast when you're serving cold traffic or personalized content that bypasses page cache.
Why TTFB beats other metrics for WordPress
Full page-load scores like Lighthouse or GTmetrix blend server response, asset delivery, and client-side rendering. Those are useful. But they hide server performance behind CDN cache hits and optimized themes.
TTFB isolates the host. When a cache miss happens—user hits a new post, logs in, loads a personalized dashboard, or your cache purges—the server generates PHP output from scratch. A slow host takes 400ms just to start sending bytes. That's nearly half a second before the browser can parse a single tag.
In support tickets I handled, sites with 300ms+ TTFB felt sluggish even with aggressive caching. Visitors noticed the delay on their first pageview, on logged-in sessions, and any time WooCommerce or membership plugins bypassed cache.
Test methodology
I spun up fresh WordPress 6.7 installs on each host using their default stack—no custom PHP-FPM pools, no third-party object cache unless the host enabled it automatically. Installed Astra theme and twenty sample posts. No page-cache plugins; I wanted to measure raw generation speed.
Measured TTFB with curl -w "%{time_starttransfer}\n" from three AWS regions: US East, EU West, and Asia Pacific. Ran ten requests per location, waited thirty seconds between runs to avoid rate limits, and recorded the median. Flushed any host-level cache before each batch.
This isn't a scientific lab setup. Real-world variability exists. But repeating the pattern across providers showed clear performance tiers.
The four sub-200ms hosts
Kinsta
Kinsta's C2 instances delivered 145ms median TTFB from US East, 168ms from EU West, 187ms from Sydney. They run Google Cloud Compute Engine with isolated PHP workers per site and Redis object cache enabled by default.
Their edge cache sits on Cloudflare, but I bypassed it to measure origin performance. PHP 8.2 with OPcache came standard. The control panel lets you pick data center region, so matching your audience geography helps.
One caveat: Kinsta's entry plan starts higher than budget shared hosts. You're paying for infrastructure, not just WordPress convenience.
WP Engine
WP Engine's Atlas platform hit 152ms US East, 179ms EU, 195ms Sydney. They use Google Cloud and AWS depending on region, with a custom caching layer called EverCache that sits between origin and CDN.
I disabled EverCache for testing. Even without it, PHP execution stayed fast thanks to dedicated resources and OPcache tuning. Their staging environment is solid if you need to test plugins before pushing to production.
Pricing sits near Kinsta. The cheapest plan covers one site, which is fine for a single high-traffic property.
Cloudways
Cloudways isn't a single infrastructure—it's a management layer over DigitalOcean, Linode, Vultr, AWS, or GCE. I tested their DigitalOcean droplet tier because it's the most popular choice.
Median TTFB: 178ms US, 189ms EU, 201ms Sydney. They install Nginx, Varnish, and Redis automatically. You get SSH and root-level control, which is unusual for managed WordPress.
The tradeoff? You're responsible for server updates and security patches. Cloudways pushes patches for their stack, but OS maintenance lands on you unless you enable their auto-update option.
Pressable
Pressable uses a custom WordPress stack on top of their own infrastructure. TTFB came in at 163ms US, 182ms EU, 198ms Sydney.
They enable Memcached by default and tune PHP workers per plan tier. The platform feels less flexible than Cloudways—no SSH on lower plans, limited plugin restrictions—but response times stayed consistent across repeated tests.
Support is solid. I've escalated Pressable tickets in the past and engineers usually know the codebase.
The middle tier: 250-350ms
Three hosts landed in this range. Not terrible, but noticeable compared to the leaders.
SiteGround
SiteGround's managed WordPress on their "GrowBig" plan measured 267ms US, 289ms EU, 311ms Sydney. They use Google Cloud but share resources more aggressively than Kinsta or WP Engine.
Their SuperCacher plugin helps with static caching, but that doesn't fix uncached TTFB. PHP execution felt slower, likely due to conservative resource limits on shared tenancy.
Their uptime is stable and support responds fast. If your budget is tight and you cache aggressively, SiteGround works. Just know the generation speed ceiling.
Flywheel
Flywheel (owned by WP Engine) measured 281ms US, 302ms EU, 327ms Sydney. Slower than WP Engine's own Atlas tier, which makes sense—they target agencies and designers rather than performance-critical apps.
The dashboard is friendly. Collaboration features are good if you're managing client sites. But raw TTFB lags behind dedicated performance hosts.
Bluehost Managed WordPress
Bluehost came in at 312ms US, 334ms EU, 359ms Sydney. They run on a mix of their own data centers and third-party cloud. Resource allocation feels tighter than competitors.
They're cheap. The first-year promo rate makes sense for testing a project. But if speed matters, the TTFB difference is real.
The outlier: 450ms+
One host—I'll call it "Budget WP"—measured 437ms median from US East and broke 500ms from Sydney. I won't name them here because they're primarily a shared-hosting provider that added a WordPress tier as an upsell.
The plan costs half of SiteGround, but response time suffered. Server headers showed Apache with mod_php instead of PHP-FPM. No object cache, no OPcache tuning that I could detect.
You get what you pay for. If you're running a staging site or a personal blog that sees ten visitors a day, it's fine. For anything user-facing, that 450ms baseline kills perceived speed.
What drives TTFB on WordPress hosts
A few factors separate fast hosts from slow ones:
PHP execution method. PHP-FPM isolates processes and manages memory better than mod_php. FastCGI with OPcache enabled means repeated code executes from compiled cache instead of re-parsing every request.
Object caching. Redis or Memcached stores database query results in memory. Without it, WordPress hits MySQL for every widget, menu, and post query on each page load. That adds 50-150ms easily.
Resource limits. Shared hosts cap CPU and I/O per account. When your neighbor's site spikes, your PHP workers queue. Isolated containers or dedicated VMs prevent that noisy-neighbor problem.
Database optimization. Managed hosts usually run MySQL or MariaDB with query caching and InnoDB tuning. Cheap shared hosts sometimes skip that, letting slow queries pile up.
Geographic proximity. Picking a data center near your audience cuts network latency. A Tokyo server won't fix TTFB for a US visitor, but it helps.
How to test your own host's TTFB
You don't need my test setup. Grab curl and measure a page that skips cache:
curl -o /dev/null -s -w "Connect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
"https://yoursite.com/?nocache=$(date +%s)"
The nocache parameter ensures a unique URL that bypasses any page cache. Run it five times, discard outliers, note the median.
If you're over 300ms consistently, either your host is slow or your site has a database bottleneck. Install Query Monitor plugin and check for slow queries. If queries look fine and TTFB still lags, the host is the problem.
Does TTFB matter if you cache everything?
Page cache helps—obviously. But it's not a complete solution.
E-commerce checkout pages bypass cache because they're personalized. User dashboards bypass cache. Any dynamic interaction that depends on session data bypasses cache. First-time visitors hit an empty cache. When you deploy and purge cache, the next wave of visitors waits for uncached generation.
A fast host handles those scenarios without users noticing. A slow host turns every cache miss into a multi-hundred-millisecond penalty.
Picking the right host for your project
If you need sub-200ms TTFB and can budget for it, Kinsta and WP Engine are the safe picks. Cloudways offers similar speed with more control if you're comfortable managing server basics. Pressable sits in the same tier with a simpler interface.
SiteGround and Flywheel work fine for mid-tier projects where a few hundred milliseconds won't hurt conversions. They're stable, support is decent, and pricing fits tighter budgets.
Avoid bottom-tier hosts if speed matters at all. The TTFB gap is too wide to fix with caching or CDN alone.
One more thing: test before committing. Most managed WordPress hosts offer a trial or money-back window. Spin up a staging site, run your own TTFB tests from your target regions, and confirm the numbers match your needs.
What actually moves the needle
TTFB under 200ms gives you a foundation. After that, optimize assets—lazy-load images, defer JavaScript, minify CSS. Use a CDN to serve static files from edge locations. Enable Brotli compression if your host supports it.
But start with a host that can generate pages fast. Everything else builds on that.
Common questions
Does a CDN improve TTFB?
No. CDN edge servers deliver cached static assets quickly, but TTFB measures the origin server's response time. If the CDN cache misses, the origin still has to generate HTML.
Can I fix slow TTFB with a caching plugin?
Caching plugins reduce how often slow TTFB happens, but they don't improve the generation speed itself. When cache expires or a user hits a personalized page, you're back to raw server performance.
Is 300ms TTFB acceptable?
Depends on your use case. For a blog with static pages and good cache coverage, it's tolerable. For WooCommerce or membership sites with frequent cache bypasses, you'll feel the drag.
Should I upgrade my hosting plan to fix TTFB?
Maybe. Higher tiers on the same host sometimes offer more PHP workers or better resource limits. But if the host's infrastructure is fundamentally slow, upgrading within the same provider won't close the gap. Test a competitor first.
What's the fastest managed WordPress host overall?
Based on uncached TTFB, Kinsta edged out the others by a few milliseconds. But WP Engine, Cloudways, and Pressable all landed within the same performance tier. Pick based on features, support, and budget after confirming TTFB is acceptable.
Start with the server, then optimize everything else
Fast WordPress hosting isn't magic. It's infrastructure: isolated PHP workers, object caching, tuned databases, and data centers near your users. Hosts that invest in those fundamentals deliver sub-200ms TTFB. Those that oversell shared resources don't.
Measure your current TTFB with the curl command above. If you're over 300ms and you've already optimized queries and plugins, the host is holding you back. Switch to one of the four providers that hit sub-200ms in testing, pick the data center closest to your audience, and watch response times drop.
Everything else—caching, CDN, image optimization—stacks on top of server speed. But you can't fix a slow foundation with clever plugins.