TTFB (Time to First Byte) is the time from the start of a navigation until the browser receives the first byte of the HTML response. It is not a Core Web Vital, but it is the first part of LCP: nothing can render before the HTML arrives. web.dev rates 0.8 seconds or less as good. To reduce TTFB in WordPress, serve cached HTML from a page cache or edge cache, add a persistent object cache (Redis or Memcached) for requests that can’t be cached, run a supported PHP version with OPcache, trim autoloaded options and slow queries, and make sure cookies and query strings don’t bypass the cache.
TTFB is where I start every WordPress audit, even though Google doesn’t score it, because a slow server makes every other fix smaller. A page with 1.8 seconds of TTFB has 0.7 seconds left to download and render its LCP element before it fails the 2.5 second threshold. For how TTFB fits with the three Core Web Vitals, see Core Web Vitals for WordPress: the complete guide.
What does TTFB include?
TTFB is more than server time. It covers everything before the first byte:
- redirects, such as
httptohttpsor a missing trailing slash - service worker startup, if the site has one
- DNS lookup
- TCP connection and TLS negotiation
- the request travelling to the server, and server processing until the first byte goes out
So a fast server can still have a poor TTFB in field data when visitors are far from it, or when campaign links go through two redirects. web.dev publishes these thresholds for TTFB, measured at the 75th percentile:
| Rating | TTFB |
|---|---|
| Good | ≤ 0.8 s |
| Needs improvement | 0.8 s to 1.8 s |
| Poor | > 1.8 s |
These are guidance values, not part of the Core Web Vitals assessment.
Why is TTFB not a Core Web Vital?
Google’s position is that TTFB is a diagnostic. Sites are built in different ways: a server-rendered WordPress page and a client-rendered app can reach the same LCP with very different TTFB, and a fast TTFB followed by a slow render is still a slow page. So Google scores what the visitor sees (LCP, INP and CLS) and leaves TTFB as a way to explain them.
On WordPress, though, the HTML usually contains everything the first screen needs, so TTFB maps almost directly onto LCP. When I see a WordPress site with poor LCP and TTFB over a second, the server is the first thing I fix. The image work in how to improve LCP in WordPress comes after.
Where does WordPress spend time before the first byte?
On an uncached request, PHP boots WordPress core, loads every active plugin and the theme, reads all autoloaded options from wp_options, runs the queries for the page, renders the template and only then starts sending HTML. Every plugin adds to that, even on pages where it does nothing visible.
| Cause | How to check | Fix |
|---|---|---|
| No page cache | Response headers such as x-cache or cf-cache-status, repeated requests with the same TTFB | Server page cache (Nginx FastCGI cache, Varnish, LiteSpeed) or a caching plugin |
| Cache bypassed by query strings | Compare TTFB with and without ?utm_source=test | Ignore marketing parameters like utm_*, gclid and fbclid in the cache key |
| Cache bypassed by cookies | Test as anonymous visitor after adding a product to the cart | Bypass only the cookies that really personalize the page |
| No persistent object cache | Site Health suggests one on larger sites that don’t have it | Redis or Memcached with an object-cache.php drop-in |
| Large autoloaded options | Site Health warns about large autoload since WordPress 6.6 | Stop autoloading options that aren’t needed on every request, clean up leftovers from removed plugins |
| Slow plugin queries | Query Monitor, slow query log | Fix or replace the plugin, add missing indexes |
| Blocking external calls during render | Query Monitor’s HTTP API calls panel | Cache remote responses with transients, move calls to cron |
| Old PHP or missing OPcache | Site Health, phpinfo() | Supported PHP version, OPcache enabled and sized for the codebase |
| Too few PHP workers | TTFB rises with traffic, requests queue | Tune PHP-FPM worker counts to the server’s memory and CPU |
| Server far from visitors | Field TTFB much worse than TTFB measured near the server | Cache HTML at the edge with a CDN |
The query string row surprises people. Every ad click arrives with a unique gclid or fbclid, and many page caches treat each one as a new URL. So the visitors you pay for are exactly the ones who get the uncached, slowest version of the page.
Page cache, object cache or edge cache?
They solve different parts of TTFB. A page cache stores the complete HTML, so anonymous visitors skip PHP and the database entirely. A persistent object cache keeps query results and computed data in memory between requests, which speeds up everything that can’t be page cached: logged-in users, WooCommerce carts and checkout, the admin. An edge cache stores HTML on CDN locations close to the visitor, which removes most of the network distance as well.
Most WordPress sites need a page cache first. Stores and membership sites need the object cache too, because a large part of their traffic is uncacheable. I compare the three in page cache, object cache or edge cache: which one you actually need.
How do I measure TTFB on WordPress?
- PageSpeed Insights shows TTFB from CrUX field data in its field section, next to the Core Web Vitals.
- Chrome DevTools shows “Waiting for server response” in the timing tab of the document request in the Network panel.
- From the command line,
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/prints TTFB in seconds. Run it several times, and with a query string, to see cached and uncached responses. - Site Health, since WordPress 6.1, checks whether a page cache is detected and reports server response time.
- A
Server-Timingresponse header lets the server report its own phases (PHP, database, cache), which DevTools displays next to the request.
Measure from where your visitors are. A test from a data center next to your server says little about a visitor on a mobile network on another continent. Field data covers that, which is why I explain the difference between field data and lab data before anyone starts tuning servers.
What TTFB should a WordPress site aim for?
Aim for 0.8 seconds or less at the 75th percentile of field data, on mobile. A cached page served from the edge should be well under that. If cached pages are fast and the field number is still poor, look at redirects, cache hit rates and the share of traffic that bypasses the cache. If uncached pages are slow, the work is in PHP, the database and plugins.
Server tuning is often work for whoever runs the infrastructure. When a client needs the implementation done, the WebOption team handles it as part of its WordPress performance and security service.
Want to know where your TTFB goes?
If your server response is slow and you don’t know whether it is the host, the cache, the database or a plugin, I can find out and tell you what to change first. See my Core Web Vitals and WordPress performance audits.