TTFB (Time to First Byte) is the time between a visitor requesting your page and the first byte arriving. It measures how fast your server thinks, before images or scripts enter the picture. When TTFB is high, everything waits. No image optimization fixes a server that takes 3 seconds to start answering.
The good news: TTFB problems are systematic. Work through these 8 fixes in order. Each targets a bigger slice of delay than the next. Don’t skip to hosting upgrades before fixing the free stuff.
The short version: enable page caching first (biggest win, free), then edge HTML caching, then make PHP fast (version + OPcache), add Redis object caching, clean the database, kill slow external calls, trim heavy plugins, and only then consider new hosting.
What’s “Too High,” Honestly?
TTFB expectations, as rough guides rather than gospel (it varies with location, page type and whether the page was cached):
- Under ~200ms: excellent. Your stack is healthy.
- ~200–600ms: normal for dynamic WordPress pages on decent hosting. Fine.
- ~600ms–1s: worth investigating: something is slow in page generation.
- Over 1s: a real problem. Visitors feel this; Google notices it too.
- Over 2s: emergency. Fix before doing any other optimization.
Two nuances. Test uncached: cached TTFB measures your cache, uncached measures your stack, and only the latter tells you what to fix (bust the cache with a random query string). And test near your server: TTFB includes network travel time, so cross-continent tests add unavoidable latency. That’s geography, not a bug; solve it with a CDN.
Measure it simply:
curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" "https://yoursite.com/?nocache=$(date +%s)"
Fix 1: Enable Page Caching (Biggest Win, Free)
An uncached WordPress request runs PHP, queries the database dozens of times, and assembles HTML from scratch — on every single visit. A page cache stores the finished HTML and serves it directly, skipping PHP and MySQL almost entirely.
This is the single largest TTFB reduction available, and it’s free: WP Rocket, FlyingPress, LiteSpeed Cache, or any solid caching plugin. On a typical site, page caching takes uncached TTFB from seconds to a tenth of a second for repeat visitors.
Caveat: page caching masks slowness rather than curing it. Logged-in users and cart/checkout pages bypass it. Take the immediate win, then keep going: uncached hits (first visits, cache clears) still hurt until generation speed is fixed.
Fix 2: Add Edge HTML Caching (Cloudflare APO and Friends)
Page caching happens on your server. Edge HTML caching happens on servers near your visitors. Cloudflare’s APO (Automatic Platform Optimization), or similar features from other CDNs, cache your HTML at 300+ global locations.
Why it matters for TTFB: a visitor in another continent gets their first byte from a nearby edge server instead of waiting for a round trip to your origin. For international audiences, this often cuts TTFB more than any server-side tweak.
It stacks with Fix 1: edge cache serves visitors far away; your page cache serves everyone else and acts as the fallback. After enabling it, test whether your CDN is actually working. Misconfigured edge caching that looks enabled but serves MISS on every request is depressingly common.
Fix 3: Modern PHP + OPcache
WordPress runs on PHP, and PHP versions differ enormously in speed. If your host still runs PHP 7.4 (or worse), you’re leaving free performance on the table. Each major PHP version has been significantly faster than the last, and old versions are also security risks. Check your Site Health (Tools → Site Health → Info → Server) and ask your host to move you to a supported PHP 8.x version.
Then make sure OPcache is enabled. OPcache stores precompiled PHP bytecode in memory, so PHP doesn’t recompile your theme and plugin files on every request. It’s usually a one-line setting in your hosting panel or php.ini (opcache.enable=1), and on hosts that manage PHP for you, it’s often already on. Verify rather than assume.
Together, current PHP + OPcache can cut PHP execution time dramatically. This fix costs nothing and takes minutes.
Fix 4: Add Redis Object Caching
Here’s what page caching doesn’t fix: every uncached request still hammers the database. WordPress runs dozens of queries per page — options, post meta, transients — and MySQL answers each one from disk (relatively slow) instead of memory (very fast).
Redis sits between WordPress and MySQL, storing query results in RAM. Repeat queries return in microseconds instead of milliseconds. The effect on uncached TTFB is substantial, especially for dynamic pages, WooCommerce, membership sites and busy admin dashboards — exactly the pages page caching can’t help.
Our guide to setting up Redis object caching for WordPress walks through the full setup. Many managed hosts offer Redis as a one-click toggle; on a VPS it’s a short install. Either way, it’s the highest-impact fix for database-driven TTFB.
Fix 5: Clean the Database and Fix Slow Queries
If Redis is the bandage, this is the cure. Common database problems behind high TTFB:
- Autoload bloat: the
wp_optionstable has anautoloadcolumn — everything markedyesloads on every page request. Plugins love dumping data here. When autoloaded data grows into megabytes, every single request pays the price before WordPress does anything useful. Find the worst offenders (Query Monitor or a dedicated plugin shows autoload sizes) and stop the bloat at its source. - Transients gone wild: expired transients that never got cleaned up, or plugins creating thousands of them.
- Post revisions and spam: tens of thousands of revisions slow down queries on large sites. Cap revisions with
WP_POST_REVISIONSand clean periodically. - Missing indexes: usually a plugin problem: a plugin querying unindexed columns on large tables. Query Monitor’s slow-query list identifies these; the fix is replacing or reporting the plugin, not hand-tuning MySQL.
Clean conservatively (back up first), and re-measure TTFB after. Database cleanup has the most dramatic effect on sites that have been running for years without maintenance.
Fix 6: Kill Slow External HTTP Calls
Your server sometimes waits on other servers before answering. Plugins make external HTTP requests during page generation: license validation, update checks, dashboard news feeds, API integrations, tracking. Each one adds its full response time to your TTFB. If the external service is slow or down, your page waits (or times out).
Find them with Query Monitor’s HTTP API Calls panel: look for external requests happening on frontend page loads, especially slow ones. Fixes:
- Cache the response in a transient so it isn’t fetched on every request.
- Move it out of the critical path: dashboard widgets and admin notices shouldn’t run on the frontend at all.
- Remove the plugin if the call serves no purpose you care about.
A single plugin phoning home to a 2-second API on every page load is indistinguishable from “slow hosting” in symptoms. But no hosting upgrade fixes it.
Fix 7: Trim Heavy Plugins and Themes
After the fixes above, whatever TTFB remains is mostly PHP execution time: your theme and plugins doing work. Audit with evidence, not superstition:
- Query Monitor shows per-plugin query counts and load time contributions.
- Deactivate suspects one at a time and re-measure uncached TTFB. (Do this on staging, or during low traffic.)
- Page builders, multipurpose themes with every feature enabled, and plugins that “do everything” are the usual heavyweights.
You don’t need a plugin count target. You need every active plugin to justify its cost in milliseconds. Replace heavy plugins with lighter single-purpose alternatives where the evidence points that way.
Fix 8: Upgrade Hosting (The TTFB Floor)
Honest truth: hosting sets the floor, not the ceiling. No fix above makes an oversold $2/month server answer in 200ms. But expensive hosting with a bloated database just runs slow code faster.
Upgrade when: fixes 1–7 are done, Query Monitor shows lean code (fast queries, no heavy plugins, no slow external calls), and uncached TTFB is still high. That’s a server problem: oversold hosting, throttled CPU, slow disks.
Look for: PHP 8.x with OPcache, Redis availability, LiteSpeed or Nginx, server-level caching, honest resource limits. Our 20-step performance checklist puts hosting where it belongs: the foundation.
Frequently Asked Questions
What’s a good TTFB for WordPress?
As a rough guide: under ~200ms is excellent, 200–600ms is normal for dynamic pages on decent hosting, over 1s deserves investigation, and over 2s is an emergency. Always compare cached vs. uncached, and test from near your server — geography adds latency no stack can remove.
Will a CDN fix high TTFB?
A CDN fixes the geography part of TTFB (visitors far from your server) and edge HTML caching (like Cloudflare APO) can dramatically cut it worldwide. But a CDN doesn’t fix a slow origin — if your uncached TTFB is 3 seconds, the CDN just caches and serves that slowness faster. Fix the origin first, then add the CDN.
Does TTFB affect SEO directly?
Google uses page experience signals in ranking, and TTFB feeds into how fast your page can possibly load — every other metric waits on the first byte. Extremely high TTFB can also cause crawl budget waste if Googlebot waits too long. Treat it as foundational: not the ranking factor itself, but the prerequisite for everything else.
Why is TTFB fine for me but slow in PageSpeed Insights?
PageSpeed Insights tests from its own servers (typically US-based). If your server is elsewhere, the field test includes real network distance. Also check whether PSI hit a cached or uncached page — lab tests sometimes measure uncached TTFB while your visitors get cached pages. Compare like with like.
I did all 8 fixes and TTFB is still high. Now what?
Recheck the basics: are you sure the page cache is serving (check response headers for HIT)? Is the slowness on every page or just some (points to specific content/plugins)? Test a plain default-theme page — if that’s fast, your theme is the problem; if that’s slow too, it’s server or network, and it’s time to talk to your host with data in hand.
The Bottom Line
TTFB is the foundation metric: it measures your server’s thinking speed before anything else matters. The fixes, in order: page cache → edge HTML cache → modern PHP + OPcache → Redis → database cleanup → kill slow external calls → trim heavy code → better hosting.
Work the list top-down, measure uncached TTFB after each step with a simple curl command, and stop when the number is sane. Most WordPress TTFB problems die at fix 1 or fix 4. The rest of the list exists for the stubborn ones.
