What Time to First Byte Measures
Time to First Byte (TTFB) measures how long it takes from the moment a visitor’s browser requests your page to the moment it receives the first byte of the response. It captures everything that happens before your content starts arriving: DNS lookup, TCP connection, TLS handshake, and server processing time. While TTFB is not one of the three Core Web Vitals, Google tracks it as a supplemental metric because it directly affects LCP and overall page load speed.
Google considers a TTFB of 800 milliseconds or less to be good. This threshold is more lenient than LCP or INP because TTFB measures only the beginning of the loading process — but a slow TTFB makes it nearly impossible to achieve a good LCP score since every other loading step must fit in the remaining time.
Why TTFB Matters
TTFB sets the floor for your page load time. No matter how optimized your images, CSS, and JavaScript are, the browser cannot start working with any of them until it receives the HTML document. A 2-second TTFB means your LCP cannot possibly be faster than 2 seconds — and in practice it will be significantly slower because the browser still needs to download and render resources after receiving the HTML.
TTFB is especially important for WordPress sites because WordPress generates pages dynamically. Each page request triggers PHP execution, database queries, and plugin processing before the server can send a response. Without caching, a content-heavy WordPress site can easily spend 1-3 seconds on server-side processing alone.
What Causes Slow TTFB
No page caching. Page caching stores the fully rendered HTML so it can be served without re-executing PHP and database queries on every request. Without it, WordPress must rebuild each page from scratch — a process that gets slower as you add plugins and content.
Slow server hardware. Shared hosting environments with limited CPU and memory resources take longer to process requests. Server response time is directly constrained by the quality of your hosting infrastructure.
Geographic distance. Data travels at the speed of light, but that still adds latency over long distances. A visitor in Tokyo requesting a page from a server in New York adds roughly 200 milliseconds of round-trip network time. A CDN can reduce this by serving cached content from a closer location.
Heavy server-side processing. Complex database queries, slow plugin hooks, and unoptimized PHP code all add to server processing time. A site with many active plugins may execute hundreds of database queries per page load, each adding a few milliseconds.
How to Recognize a TTFB Problem
PageSpeed Insights shows TTFB in both its field data and lab data sections. The field data is more meaningful because it reflects the geographic distribution of your real visitors and real-world server conditions. Google Search Console does not report TTFB directly, but a poor LCP combined with lab diagnostics pointing to “Reduce server response times” strongly suggests a TTFB issue.
In Chrome DevTools, the Network panel shows the “Waiting (TTFB)” time for the initial HTML document request. If this number is consistently above 600 milliseconds, your server response time deserves attention. Keep in mind that lab measurements from your own computer may understate the problem — your visitors may be farther from your server or testing during peak traffic.
Further Reading
- Time to First Byte (web.dev) — Google’s guide to understanding and measuring TTFB.
- CrUX Methodology: TTFB (Chrome for Developers) — How Chrome measures TTFB from real users in the field.