TTFB: Why Your Server Is the First Bottleneck (and How to Fix It)

Time To First Byte is the quiet killer of WordPress performance. It’s the delay between a visitor requesting your page and the very first byte of HTML arriving. Everything else — rendering, images, scripts — happens after it. If TTFB is 1.2 seconds, a 2.5-second LCP is nearly impossible.

What counts as slow

• Under 200 ms — excellent; this is where well-configured sites live.
• 200–400 ms — good.
• 400–800 ms — mediocre; you’re losing LCP headroom.
• Over 800 ms — a red-zone problem to fix before anything else.

Google’s CrUX dataset tracks TTFB for real users; our Site Analyzer shows yours alongside Core Web Vitals.

Why WordPress TTFB gets bad

For every uncached request, WordPress boots PHP, loads every active plugin, runs dozens of database queries, assembles the theme and only then starts sending HTML. Five things make that pipeline slow:

1. No full-page caching

The single biggest factor. With full-page caching, repeat requests skip PHP and MySQL entirely and get a stored HTML file in a few milliseconds. Without it, every visitor pays the full cost of your plugin stack. Whether that cache should be a plugin or the server’s job — see our caching comparison.

2. Heavy plugins on the boot path

Every active plugin loads on every request — including admin-ajax calls and pages where the plugin does nothing. Security suites, “multipurpose” toolkits and page builders are the usual heavyweights. This is why plugin bloat shows up in TTFB, not just page weight.

3. Slow database

Autoloaded options growing past 1 MB, expired transients by the thousand, wp_postmeta tables with millions of orphaned rows. Every request drags this anchor. Cleaning autoload data alone regularly shaves 100–300 ms on older sites.

4. Outdated PHP

PHP 8.3 is roughly 2–3× faster than PHP 7.4 in real workloads, and OPcache should always be on. Many hosts still default to old versions — check yours in one click at the hosting panel.

5. Cheap or distant hosting

Oversold shared hosting means you’re queueing behind someone else’s cron jobs. And physics matters: if your server is in Frankfurt and your customers are in Chicago, add ~100 ms before anything else happens. A CDN in front of the site (with page caching at the edge) fixes the distance problem.

The fix, in order

1. Turn on full-page caching — at the server/host level if available, otherwise a well-configured plugin. Expected result: cached TTFB under 200 ms.
2. Upgrade PHP to 8.3+ and confirm OPcache is enabled.
3. Audit plugins. Deactivate, measure, repeat. You’re looking for the two or three that dominate boot time.
4. Clean the database. Autoloaded options under ~800 KB, transients purged, revisions capped.
5. Add a CDN with edge caching if your audience is far from the origin server.
6. If all else fails, move hosts. A 20/monthVPSwithmodernPHProutinelybeatsa5 shared plan by 500 ms.

The caveat nobody mentions

Caching hides back-end cost; it doesn’t remove it. Logged-in users, cart and checkout pages, search results and the first visitor after every cache purge still hit the slow path. If your uncached TTFB is 1.5 s, your site is fragile — one cache misconfiguration away from being slow for everyone.

That’s the argument for fixing the root cause: fewer plugins, leaner queries, cleaner code. A refactored site is fast before the cache — the cache just makes it instant.

Check where you stand: run the free audit and look at the “Server Response” card. Under 400 ms cached? Good. Now go look at your uncached number.