You open a ticket with your hosting company about a slow WordPress site and they tell you to disable plugins. You point at a 3+ second TTFB and get a canned reply about your theme. We see this every week. Plugins do cause slowness, and many shared hosts are overcrowded or throttled. Both can be true. The fix is to prove where the delay starts - and if the platform is the problem, research a better host and move. Tweaking on bad hardware is wasted time.

We’ve moved plenty of sites off underpowered hosting and watched speed jump with zero code changes. InMotionHosting and GoDaddy are the repeat offenders in our inbox. After a clean move, TTFB drops, cached pages snap to life, and support tickets stop. We wrote up why in our post on the worst hosting companies.

What TTFB Really Measures

TTFB is the time to the first byte of the HTML response. For WordPress, that number includes PHP execution, database queries, external calls, and the server’s ability to run them quickly. If a static file is slow, that points to hosting or network. If a static file is fast and a simple PHP page is slow, code or plugins are in the way. If a cached page is fast but an uncached page crawls, the host may be fine but your dynamic work is heavy.

Targets we use:

  • Static file: under 200 ms (US test)

  • Cached HTML: under 200 ms is great, under 500 ms still OK

  • Uncached HTML: under 800 ms for a simple site; heavier shops will be higher, but not multi-seconds on every request

Three Proof Tests That End The Ping-Pong

Run these and save screenshots. They turn opinions into evidence.

  1. Static file
    Create /test.html with the word hello. Test from two regions. If TTFB is 800 ms–3 s, the platform is dragging.

  2. Bare PHP
    Create /test.php with:

<?php echo "ok";

If this is fast but your homepage is slow, the delay lives in WordPress code, queries, or third-party calls.

  1. Cached vs uncached
    Turn on full-page caching, warm the cache, and test the same URL twice. If cached is under 200 ms and uncached is 2–3 s, you have dynamic bottlenecks. If both are slow, the host is the blocker.

We keep a post with scanner/profiler tools that help here.

The Two Biggest Culprits

Hosting that can’t keep up
Oversold shared plans, tight PHP worker limits, slow disks, overloaded MySQL. Symptom: slow static files and slow cached HTML even on a simple site.

Heavy plugins and builders
Elementor is the top offender in our audits. Add several add-ons, a security suite doing heavy checks, popups, and slow queries on big postmeta and you’ll grind TTFB.

When To Stop Optimizing And Switch Hosts

You can spend days trimming plugins and still fight the platform. Move when any of this is true:

  • Static /test.html TTFB is consistently over 500–800 ms from multiple regions

  • Cached HTML stays over 500–800 ms even after you warm it

  • Support won’t discuss PHP workers, IO limits, database load, or node health and keeps sending plugin scripts

  • You see “resource limits reached” or queued PHP workers during small traffic spikes

At that point, switching is the fastest “optimization.” Research a better host, run the same tests on a clone, compare, and move. We see immediate gains with no code changes, which is the clearest proof your current platform is the ceiling.

What “Better Hosting” Actually Looks Like

You don’t need exotic hardware - just sane defaults and headroom.

  • Solid choices we see perform: WP Engine, GreenGeeks, Cloudways, SiteGround. Hetzner is strong value if you manage your own stack.

  • Minimum specs we set on a small cloud box: 2 CPU, 2 GB RAM, SSD or NVMe

  • Features that matter: server-level full-page cache, Redis or Memcached for object cache, current PHP, HTTP/2 or HTTP/3, Brotli, NVMe, clear published limits

We prefer cloud hosting because it gives the most control: pick the box size, tune PHP workers, scale without platform lock-in.

WordPress Changes That Actually Move TTFB

  • Full-page cache with WP Rocket plus Cloudflare. Cache everything that isn’t cart/checkout/account. Warm your key URLs.

  • Object cache (Redis) for logged-in views and Woo fragments.

  • Kill or delay external calls that block first byte. CRM and email pings shouldn’t run before HTML ships.

  • Replace heavy plugins with lighter options or native code where it makes sense.

  • Hunt slow queries. Postmeta scans across big tables are common - fix with indexes and smarter queries.

How To Run A Fair Comparison Before You Move

  1. Capture baselines: static, bare PHP, cached, uncached - record waterfalls and headers.

  2. Clone to a better host (or small VPS): same code, same DB, same cache.

  3. Decide with numbers: if static and cached drop from ~1 s to <200 ms on the new host, the platform was the bottleneck. If uncached stays slow in both places, refactor plugins/queries.

Real example: a local services site on crowded shared hosting had uncached TTFB at 2.8 s, cached at 1.6 s, static at 1.2 s. We moved it to a managed plan with NVMe and Redis - same theme and plugins. Cached fell to 90 ms, uncached to 520 ms. No code rewrites.

  • Hosting: WP Engine, GreenGeeks, Cloudways, SiteGround; Hetzner if you self-manage

  • Specs: 2 CPU, 2 GB RAM, SSD/NVMe minimum; add resources for Woo or heavy plugins

  • Caching: WP Rocket + Cloudflare; enable HTTP/2 or 3, Brotli; bypass cache on cart/checkout

  • Object cache: Redis with sensible TTLs

  • Builder: avoid Elementor if you can; if you keep it, limit add-ons and audit includes per page

What To Send Your Host (So They Take It Seriously)

Support responds to evidence. Share three screenshots:

  • TTFB of /test.html from two regions

  • TTFB of /test.php from two regions

  • TTFB of your homepage cached and uncached

If static and cached are slow, ask about PHP workers, IO limits, disk type, and node load. If they still point at plugins after you’ve shown static slowness, research and switch. It’s faster than arguing.

FAQ

Isn’t TTFB always a plugin problem
No. TTFB includes server capability. If static files and cached HTML are slow, that’s the platform. Plugins can hurt TTFB, but slow static = host.

Which hosts do you see underperform the most
InMotionHosting and GoDaddy are repeat offenders in our tickets. We break down why here: worst hosting companies.

What numbers should I aim for
Static and cached under 200 ms (US). Uncached under ~800 ms for simpler sites. Multi-second first bytes across the board signal a real bottleneck.

What’s your go-to setup
WP Rocket + Cloudflare on top of a host with NVMe, current PHP, Redis, and reasonable worker limits. Avoid Elementor if you can; keep add-ons minimal if you can’t.

Can you handle the move
Yes. We audit, run the tests, fix plugin/query bottlenecks, and migrate you to a host that can carry the load. You get before/after numbers and a simple plan to keep it fast.

For tooling to run the proofs, check our scanner tools guide. And if you’re tired of back-and-forth, we’ll run the tests, share the results, and either tune your stack or move it - whichever gets you under that 500 ms target fastest.