Time to First Byte is the most misdiagnosed metric in WordPress performance. When a page feels sluggish, the reflex is to compress images, lazy-load video, and minify CSS. None of that touches TTFB. TTFB is the time between the browser sending a request and the very first byte of the response coming back — it is pure server-and-network latency that happens before a single pixel can render. If your TTFB is bad, no amount of front-end tuning will save you, because the browser is sitting idle waiting for your server to finish thinking.

Google considers a TTFB under 800ms "good," and a well-cached WordPress site should comfortably hit 100–300ms. Because TTFB is a direct input to Largest Contentful Paint (your LCP target is under 2.5s), a slow first byte eats into the entire budget you have for the visible page. Let's diagnose where the delay actually comes from, then fix it with four server-side levers — in roughly the order of impact.

First, measure it properly

You cannot fix what you have not isolated. TTFB hides inside several "loading" numbers, so measure it specifically:

Chrome DevTools → Network tab: click your document request (the HTML, not assets), open Timing, and read the Waiting for server response (TTFB) value. This is the number that matters.
WebPageTest: run a test from a location near your audience and read the "First Byte" column. It separates DNS, connect, TLS, and TTFB so you can see whether the delay is network or server.
curl, the fastest gut check: curl -w "%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com/ prints seconds to first byte with no browser noise.

Test both a logged-out page and a logged-in page (or your cart/checkout). Those two numbers often differ by an order of magnitude, and the gap tells you whether your problem is caching or raw server speed.

Fix 1: Serve full-page cache so PHP and MySQL never run

On a cache miss, every WordPress request boots PHP, loads plugins, runs dozens of database queries, and assembles HTML — easily 300ms to over a second of work. A full-page cache stores the finished HTML and serves it on subsequent hits without touching PHP or MySQL at all. This is the single largest TTFB win for most sites.

Your options, roughly best to most universal:

Server-level caching is fastest: LiteSpeed Cache (if your host runs LiteSpeed/OpenLiteSpeed) or Nginx FastCGI cache / Varnish. These serve cached HTML from the web server before PHP is even invoked.
WP Rocket is the easiest plugin route — enable page caching and it works out of the box, generating static pages on the fly.
W3 Total Cache or the free LiteSpeed Cache plugin if you want a no-cost option.

The catch: caching only helps pages it is allowed to cache. WooCommerce carts, account pages, and anything personalized must be excluded, which is exactly why dynamic TTFB is a separate problem — see Fix 2.

Fix 2: Fix the uncached path — host, PHP version, and object cache

Cached HTML is wonderful until a logged-in user, a search query, or a checkout forces WordPress to actually execute. That uncached path is where TTFB quietly rots, and it comes down to three things:

PHP version

Run PHP 8.1 or newer. PHP 8.x is dramatically faster than 7.4, and 7.4 is years past end-of-life. Most hosts let you switch the PHP version from the control panel in one click; test on staging because very old plugins occasionally choke.

Persistent object cache

By default WordPress only caches objects for a single request. A persistent object cache with Redis or Memcached keeps query results and computed values in memory across requests, slashing repeated database work on dynamic pages. Managed hosts like Kinsta and WP Engine offer it natively; on a VPS, install Redis and the Redis Object Cache plugin.

The host itself

Oversold shared hosting is the most common hidden cause of bad TTFB — your site competes with hundreds of others for CPU, so even cached responses queue. If your fundamentals are correct and TTFB is still high, the box is the bottleneck. Quality managed WordPress hosts (Kinsta, WP Engine, SiteGround's higher tiers, Cloudways) exist largely to make this number small.

Fix 3: Cache the HTML at the edge with a CDN

Even a fast origin in Virginia means a 150–250ms round trip for a visitor in Sydney before your server does anything. A CDN that caches your HTML — not just images and CSS — answers from a city near the user, collapsing that distance.

This is a real distinction: most people use a CDN only for static assets, which does nothing for the HTML document's TTFB. To cache the page itself at the edge:

Cloudflare cache rules let you cache HTML for anonymous visitors. (Note: Cloudflare's old Automatic Platform Optimization for WordPress was retired, so configure cache rules directly rather than looking for APO.)
QUIC.cloud, built by the LiteSpeed team, offers edge page caching that integrates with the LiteSpeed Cache plugin.
Several managed hosts now bundle edge HTML caching — check whether yours does before bolting on a third party.

As always, exclude logged-in and transactional traffic from edge caching so users do not see each other's personalized pages.

Fix 4: Cut the per-request work WordPress can't avoid

For traffic that genuinely cannot be cached, your only lever is making each request cheaper. This is unglamorous profiling work, and it pays off on exactly the pages caches can't help:

Profile with Query Monitor. Install it, load a slow page while logged in, and read the database panel. It surfaces slow queries, the plugins responsible, and total query time — your map of where the milliseconds go.
Hunt autoloaded options bloat. Abandoned plugins dump huge serialized blobs into wp_options with autoload = yes, loaded on every single request. Query the autoloaded size; if it's into the megabytes, clean it.
Kill synchronous external calls in the request path. A plugin that pings a license server or social API on init adds that network latency to every page's TTFB. Move such calls to cron or async, or replace the plugin.
Audit plugins that run on every init. Page builders, analytics, and "do everything" suites add baseline overhead whether or not their feature is used on that page. Fewer, leaner plugins mean a lower TTFB floor.

The order that actually works

Start by measuring so you know your baseline and whether the problem is on cached or uncached requests. Turn on full-page caching first — it's the biggest single win. Then make sure the uncached path is healthy with modern PHP and an object cache, because caching can't cover carts and logins. Add an edge CDN if your audience is geographically spread. And keep per-request work lean so dynamic pages stay fast. Do those four things and a 900ms first byte routinely drops into the 100–300ms range — and your LCP finally has room to breathe.

Why Your TTFB Is Slow (and 4 Ways to Fix It)