What Is Time to First Byte (TTFB), and Why Does It Matter?

Time to First Byte (TTFB) measures how long it takes, from the moment a browser asks for a page, until the very first byte of the response comes back. It's the gap between "I'd like this page, please" and the server starting to hand it over. Nothing a visitor sees can happen until that first byte arrives — which is exactly why TTFB matters more than its quiet, behind-the-scenes name suggests.

What TTFB actually measures

TTFB isn't a single thing; it's the sum of a few steps that happen before any content downloads:

• DNS lookup — turning your domain name into an address. Usually a few milliseconds, but a slow or poorly configured DNS provider adds delay to every first visit.
• Connection and TLS — the TCP handshake and the TLS negotiation needed to open a secure connection.
• Redirects — if the URL bounces (http → https, then www → non-www) before landing, each hop counts. A chain of redirects is a chain of round trips.
• Server think-time — the big one: how long your server takes to build the page once it has the request. For WordPress that means PHP running, plugins loading, and the database being queried.
• The first byte on the wire — the trip from the server back to the browser, which is mostly a function of distance.

It's worth being clear about what TTFB is not: it's a server-responsiveness signal, not one of Google's three Core Web Vitals (LCP, INP, CLS — see our intro to Core Web Vitals). But it is the first sub-part of LCP and it sits underneath every other metric, which is why it's reported alongside them.

What counts as good

Google's current guidance puts the targets here, measured at the 75th percentile of real visits (field data, not a single lab test):

Google treats under 800ms as the bar most sites should clear. Faster is always better — a well-cached WordPress site on good hosting often lands comfortably under 200ms — but 800ms is the line that keeps TTFB from dragging the rest of your metrics down.

Why it matters

TTFB is the starting gun for the whole page. Because Largest Contentful Paint (LCP) can't begin until the first byte arrives, a slow TTFB sets a floor under your LCP that no amount of image optimisation can lift. Shave 500ms off TTFB and every metric downstream gets that head start for free.

What actually drives TTFB on WordPress

On a WordPress site the biggest driver, by a wide margin, is server think-time on uncached pages: PHP booting WordPress, every active plugin loading, and the database answering dozens of queries — all before a single byte can leave. Everything else above is usually a rounding error next to that, so the fixes are almost all server-side:

• Full-page caching. When a finished page can be served straight from cache — a server-level FastCGI/nginx cache, or a caching plugin if that's what you have — the server skips the PHP and database work entirely. This is the single biggest win available.
• Object caching (Redis). For pages that can't be cached whole (logged-in users, carts, personalised content), Redis keeps repeated database lookups in memory so PHP isn't waiting on the database for every request.
• A current PHP version. PHP 8.2 or 8.3 is meaningfully faster than the 7.x and 8.0 versions still running on a lot of older hosting.
• A CDN edge. Serving from a location closer to the visitor shortens the round trip, and a CDN that caches full HTML can answer without touching your server at all.

Honestly, this is mostly a hosting problem

Look at that list again: caching layers, Redis, PHP versions, CDN configuration, server capacity. None of it is something you edit in your content, and most of it isn't something you should be configuring by hand. That's precisely the part a managed host should be handling for you, so a slow first byte never becomes your problem to chase.

If your TTFB is poor and your host hasn't set up server-level page caching, a current PHP version, and an object cache, that's the conversation to have first — before touching anything on the site itself.

The couple of things you do control

A few things on the site side can undo good hosting, and they're worth a look:

• Redirect chains. Make sure your domain lands in one hop. If a link goes http → https → www → final URL, that's three round trips before the server even starts thinking. Pick one canonical URL and redirect straight to it.
• Plugin bloat. Every active plugin adds PHP work on uncached page loads, and a badly written one can add slow database queries on every request. Deactivate what you don't use.
• Giant, uncached pages. Pages that bypass the cache — because of a query string, a logged-in state, or a plugin that marks everything "dynamic" — hit PHP every time. The fewer of those, the better.

Get those right, with a host doing its part, and 800ms stops being a target and becomes a comfortable margin.