A high Time to First Byte is the most misdiagnosed problem in WordPress performance. People see a 1.4-second TTFB in PageSpeed Insights, blame the theme, swap in a "lightweight" one, and watch the number refuse to move. That's because TTFB lives almost entirely on the server, before a single pixel renders. This article walks the WordPress request lifecycle from the inside out, shows you where the milliseconds actually accumulate, and gives you the fix that matches your specific situation.

What a "good" TTFB actually is

Google's documented threshold is under 800ms for the 75th percentile of real-user visits, and TTFB feeds directly into your Largest Contentful Paint budget of 2.5 seconds. But 800ms is a ceiling, not a goal. A well-tuned WordPress site on decent hosting should serve a cached page in 100–300ms from the visitor's region. If you're seeing 600ms or more on repeat loads, something is making the server work that shouldn't be.

The critical distinction most guides skip: measure TTFB for a cache HIT and a cache MISS separately. A cached page and an uncached page travel completely different code paths. Lump them together and your diagnosis will be wrong.

Separate the network from the server

Before you touch WordPress, find out how much of your TTFB is even WordPress's fault. Run:

curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com/

Run it twice. The first request warms the cache; the second tells the truth. If time_appconnect (DNS + TCP + TLS) is already 400ms, your problem is geography or DNS, not PHP — no amount of caching will help. If the gap between time_appconnect and time_starttransfer is large, that gap is your server processing time, and that's what the rest of this article fixes.

The WordPress request lifecycle, and where time leaks

On a cache MISS, every WordPress request does roughly this: bootstrap PHP and load wp-load.php, connect to MySQL, load every active plugin's main file, fire the init and wp hooks, run the main query, render the theme template, and assemble the HTML. Slow TTFB means one of these stages is bloated. Here is how to find which one — and what to do.

1. Full-page caching: the single biggest lever

If a logged-out visitor triggers PHP and MySQL on every request, you have already lost. Full-page caching stores the finished HTML and serves it without booting WordPress at all, which is why it routinely drops TTFB from 900ms to under 150ms in one move.

Verify it's working by checking response headers (curl -I https://yoursite.com/) for a cache indicator: x-litespeed-cache: hit, cf-cache-status: HIT, x-cache: HIT, or your host's equivalent. A MISS on every reload means the cache is misconfigured or being bypassed.

Common reasons a cache silently doesn't fire: a stray cookie (analytics, a "EU consent" plugin, or an abandoned-cart cookie) makes every visitor look unique; a session-starting plugin calls session_start(); or the page sets Cache-Control: no-cache from a misbehaving plugin. On LiteSpeed hosts use LiteSpeed Cache (it ties into the server's LSCache and is the fastest option); elsewhere WP Rocket or Cache Enabler work well. On Cloudflare you can enable APO (Automatic Platform Optimization) to cache HTML at the edge.

2. Object caching for everything that can't be page-cached

Page caching does nothing for logged-in users, WooCommerce carts, or AJAX endpoints — those always run PHP. This is where a persistent object cache earns its keep. By default WordPress recomputes the same database results on every request; Redis or Memcached holds them in memory between requests.

For a content site the win is modest, but for WooCommerce or a membership site it's transformative — admin and account pages that took 1.2s can drop to 300ms. Install Redis Object Cache (the plugin by Till Krüss) if your host offers Redis; managed hosts like Kinsta, WP Engine, and Cloudways provide it on request or by default. Confirm it's active under Settings → Redis showing "Connected," or via Query Monitor's cache hit ratio.

3. Find the plugin that's querying too much

Install Query Monitor (free) and load an uncached page while logged in as admin. The admin bar shows total query count and time. Over ~150 queries or 400ms of DB time on a simple page points to a culprit. Open Queries → Queries by Component to rank plugins by database time.

The usual offenders: related-posts plugins running unbounded WHERE queries, sliders or "popular posts" widgets that recount on every load, and ACG/ACF setups pulling dozens of meta rows per post. The fix depends on the plugin — switch to a related-posts tool that precomputes relationships, cache the widget output, or reduce the meta footprint. Don't just optimize the database table; OPTIMIZE TABLE rarely buys more than 10–30ms and won't fix an N+1 query pattern.

4. PHP version and OPcache

Running PHP 7.4 in 2026 is leaving real speed on the table — PHP 8.2 or 8.3 is meaningfully faster at the same workload, and 7.4 is years past end-of-life. Check under Tools → Site Health → Info → Server. Equally important is OPcache, which caches compiled PHP bytecode so the interpreter doesn't re-parse every file on every request. Most managed hosts enable it; on a generic VPS or budget shared plan it may be off, and turning it on can shave 100–200ms off every PHP-executing request.

5. External HTTP calls blocking the response

Some plugins make outbound API calls during page generation — license checks, font fetches, social-share counts, "ping home" telemetry. Each one stalls TTFB while WordPress waits on a third party. In Query Monitor, open the HTTP API Calls panel. Any blocking request here is added to your TTFB. The fix is to cache the response (a license check belongs in a daily transient, not every page load) or disable the feature triggering it.

6. WP-Cron firing on the visitor's request

WordPress's pseudo-cron runs scheduled tasks by piggybacking on a random visitor's page load. On a busy site, or one with a stuck heavy job, that unlucky visitor eats the full task time as TTFB. Disable the on-request trigger by adding define('DISABLE_WP_CRON', true); to wp-config.php, then schedule a real server cron to hit wp-cron.php every 5 minutes. This removes a whole class of intermittent TTFB spikes that are maddening to reproduce.

When the answer is the host

If page caching is confirmed working, object caching is on, and a cache HIT still returns 500ms+ from your own region, you've hit the hosting ceiling. Oversold shared plans throttle CPU and run dozens of accounts per server. Moving from budget shared hosting to managed WordPress hosting (Kinsta, WP Engine) or a tuned LiteSpeed host typically cuts TTFB by 300–500ms, mostly because of better hardware, NVMe storage, server-level caching, and far fewer neighbors. Pair any host with a CDN that caches HTML at the edge so visitors are served from a nearby city rather than your origin — that alone can erase the geographic portion you measured in step two.

The short version

Measure server time separately from network time. Confirm full-page caching actually fires for logged-out users. Add object caching for the logged-in paths page caching can't touch. Use Query Monitor to find the over-querying plugin and the blocking external call. Get on PHP 8.2+ with OPcache, move cron off the request, and if a cache HIT is still slow after all that, your host is the bottleneck. Work in that order and you'll spend your time on the change that actually moves the number.

Why Your WordPress TTFB Is Slow (And Specific Fixes)