Time-to-first-byte tells you how fast a host's edge network reacts before your WordPress site even renders. I tested six managed WordPress providers with identical WooCommerce installs—same plugins, same theme, same product count—and measured TTFB from multiple continents. The differences were bigger than I expected.
Edge cache hit rates matter, but TTFB measures the moment between a browser request and the first byte leaving the origin or edge node. A host can promise "99.9% uptime" and still deliver 800ms TTFB because the server stack is bloated or the edge PoP is three countries away. For WooCommerce stores, where cart and checkout pages bypass most caching, origin TTFB becomes the bottleneck.
Why TTFB matters for managed WordPress
Core Web Vitals care about Largest Contentful Paint, but LCP starts counting only after the HTML arrives. A 600ms TTFB eats half your paint budget before a single pixel renders. I've seen stores lose 15% of mobile conversions because the server took 900ms to spit out the first byte of a product page.
Managed WordPress hosts control the entire stack—PHP version, opcache settings, object cache, edge PoP placement. You're paying for that control. If TTFB is still over 400ms on a standard WooCommerce install, something in that stack is misconfigured or under-resourced.
What slows down TTFB
Three usual culprits:
- Database queries that run before WordPress outputs headers. WooCommerce loves autoloaded options; a bloated options table adds 50-100ms per request.
- Edge PoP distance. If the nearest node is 2,000km away, you're burning 40-80ms on network latency before the request even reaches the origin.
- Overloaded PHP workers. Managed hosts often share CPU cores across tenants. When your neighbor's cron job spikes, your TTFB spikes.
Object caching (Redis or Memcached) cuts database round-trips, but only if the host pre-warms the cache and tunes the eviction policy. Half the providers I tested had Redis installed but not configured as a persistent object cache—WordPress was still hitting MySQL for every autoloaded option.
Test methodology
I deployed the same WordPress 6.6 install on each host:
- Theme: Storefront (WooCommerce default)
- Plugins: WooCommerce 9.1, Yoast SEO, WP Rocket (where allowed; some hosts ban third-party caching)
- Products: 50 simple products, 10 variable products
- Traffic: simulated with
curlfrom five regions (US East, EU West, Asia Pacific, South America, Africa) over three days, hourly samples - Metric: median TTFB for the shop archive page (edge cache miss) and a single product page (also cache miss)
I cleared edge caches before each batch to measure origin TTFB, then let caches warm for 24 hours and re-tested. Both numbers matter: origin TTFB for dynamic pages (cart, checkout), edge TTFB for cached pages (homepage, archives).
The rankings
1. Host A – sub-200ms origin, global edge
Median origin TTFB: ~180ms. Edge TTFB: ~90ms after cache warm-up. Host A runs LiteSpeed with LSCache and positions edge nodes in 28 cities. The LSCache plugin integrates with WooCommerce to cache product pages aggressively while excluding cart and checkout.
PHP 8.3 is default, opcache and JIT are on, Redis object cache is pre-configured. I didn't touch any settings. The dashboard shows real-time cache hit rates broken down by post type. Support tickets I've handled with this host rarely involve performance—it's usually DNS propagation questions.
Downside: pricey. Entry tier starts higher than competitors, and you pay extra for staging environments beyond the first one.
2. Host B – consistent, excellent US performance
Median origin TTFB: ~210ms in North America, ~320ms in Europe and Asia. Edge TTFB: ~110ms globally after warm-up. Host B uses Google Cloud with custom Nginx + PHP-FPM tuning. The edge network is smaller (12 PoPs), so requests from Africa and South America route through Europe or North America.
Redis is optional and costs extra, but enabling it dropped origin TTFB by 70ms. The dashboard is clean—one-click staging, built-in CDN with Brotli compression, automatic image optimization. I've migrated a dozen WooCommerce stores here; TTFB stays stable even during traffic spikes.
Downside: Asia-Pacific latency lags behind Host A and Host C. If your customers are in Australia or Japan, test before committing.
3. Host C – best for international WooCommerce
Median origin TTFB: ~230ms globally. Edge TTFB: ~100ms. Host C runs on Cloudflare Workers at the edge with origin servers in six continents. Dynamic requests hit the nearest origin instead of routing to a central data center.
WooCommerce session handling works out of the box because they bypass cookies for static assets but preserve them for cart/checkout. The built-in WAF caught three scraper bots during my test; TTFB didn't spike. Redis and Memcached are both available; I used Redis and saw consistent 220-240ms origin times regardless of request location.
Downside: limited plugin compatibility. They block a few popular caching plugins (WP Super Cache, W3 Total Cache) because they conflict with edge caching. If your stack depends on those, you'll need to refactor.
4. Host D – solid mid-tier, occasional spikes
Median origin TTFB: ~280ms, but 95th percentile crept to ~650ms. Edge TTFB: ~130ms. Host D uses AWS with Varnish in front. Most requests were fast, but a few per hour spiked—probably PHP worker contention. I opened a ticket; support said my plan shares CPU cores across 40 accounts.
Upgrading to the next tier (isolated cores) would likely fix it, but that doubles the monthly cost. Redis is included, opcache is on, and the dashboard has decent analytics. I'd recommend this host for low-traffic sites or if you're okay with occasional 600ms outliers.
Downside: unpredictable tail latency. If you run ads or rely on predictable page speed, the spikes will hurt conversion rates.
5. Host E – budget option, slower origin
Median origin TTFB: ~420ms. Edge TTFB: ~150ms after warm-up. Host E markets itself as "affordable managed WordPress" and delivers what you pay for. Servers are older Xeon CPUs, PHP 8.2 is available but you have to enable it manually, and Redis costs extra.
I enabled Redis and saw origin TTFB drop to ~340ms—still slower than the top four. The edge network is Cloudflare Enterprise with 20 PoPs, so cached pages load reasonably fast, but any dynamic page (product filters, cart updates) feels sluggish. Support tickets take 12-24 hours to get a reply.
Downside: you get what you pay for. Fine for brochure sites, rough for WooCommerce stores with real traffic.
6. Host F – inconsistent, poor edge integration
Median origin TTFB: ~380ms, with wild variance (some requests hit 1.2 seconds). Edge TTFB: ~200ms. Host F's edge cache seemed misconfigured—cache hit rates hovered around 40% even after 48 hours of warm-up. I checked the headers and saw Cache-Control: no-cache on pages that should have been cached.
I contacted support. They said the CDN integration requires manually adding a plugin and configuring purge rules. Once I did that, edge TTFB improved to ~180ms, but origin TTFB stayed slow. The dashboard looks modern but hides important settings three menus deep.
Downside: requires too much manual config for a "managed" host. If you're comfortable tweaking cache headers and plugin settings, you'll get decent performance. If you want true hands-off management, skip it.
What good TTFB looks like
For WooCommerce on managed WordPress, aim for:
- Origin TTFB (cache miss): under 300ms
- Edge TTFB (cache hit): under 150ms
If you're seeing 500ms+ on origin, check these first:
- Object cache. Is Redis or Memcached installed and active? Run
wp cache info(WP-CLI) or check the WordPress admin → Settings → Redis (if you have the Redis Object Cache plugin). If it says "Not connected," your host installed it but didn't configure it. - Autoloaded options. Run this SQL query:
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';
If the result is over 1MB, you've got bloat. WooCommerce plugins love storing session data and transients as autoloaded options. Clean them with a query or use the WP-Optimize plugin.
-
PHP version and opcache. Check
phpinfo()or ask support. PHP 8.1+ with opcache.enable=1 should be standard in 2026. If they're still on PHP 7.4, migrate. -
Database location. Some hosts put MySQL on a separate server. If the DB is 50ms away (different availability zone or region), every query adds latency. Ask support if your DB is co-located with your web server.
Edge cache vs origin speed
Edge caching helps with repeat visitors and static pages (homepage, blog archive), but WooCommerce stores generate tons of dynamic requests:
- Cart page (always dynamic)
- Checkout page (always dynamic)
- Product pages with personalized pricing or inventory checks
- My Account pages
These bypass the edge cache and hit the origin. If your origin TTFB is 500ms, every checkout step feels slow. Customers bounce. I've seen WooCommerce stores improve mobile conversion by 8-12% just by switching to a host with sub-250ms origin TTFB.
Edge TTFB matters for SEO and first-time visitors, but repeat customers and logged-in users experience origin TTFB. Optimize both.
Testing TTFB yourself
curl is the easiest tool:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourstore.com/shop/
Run it ten times and take the median. For multi-region testing, use WebPageTest or GTmetrix. Set the test location to match your customer base—if 70% of your traffic is from Europe, test from London or Frankfurt, not California.
Browser DevTools also show TTFB under the Network tab ("Waiting" time), but the numbers fluctuate based on your local connection. Command-line tests from a VPS give more consistent results.
Does cheaper hosting ever win?
Rarely. I tested one unmanaged VPS (Hetzner, 4 vCPU, 8GB RAM, self-installed Nginx + PHP-FPM + Redis) and got ~240ms origin TTFB—better than Host D, E, and F—but I spent four hours configuring it. Managed WordPress hosting charges you for that four hours (plus ongoing maintenance, security patches, and support). If your time is worth $50/hour, the $200 setup savings evaporates.
For high-traffic WooCommerce stores (>100k monthly visitors), a tuned VPS or dedicated server will beat managed WordPress on raw TTFB, but you're doing the tuning. For everyone else, pay for a host in the top three.
Pick the host that matches your traffic
Host A wins on raw speed, but costs more. Host B and Host C both deliver sub-250ms origin TTFB at reasonable prices—pick B if your customers are mainly US/Europe, pick C if you serve a global audience. Host D works for small stores with predictable traffic, but the CPU sharing causes occasional slowdowns. Avoid Host E and F unless budget is the only constraint.
TTFB is the gate every request passes through. Choose a host that keeps that gate open.