Performance
Time to first byte
Also called TTFB.
Time to first byte is the time from the browser starting a request to receiving the first byte of the response. It covers redirects, DNS, connection setup, and server think time.
How it is measured
In the browser, `performance.getEntriesByType('navigation')[0].responseStart` gives TTFB in milliseconds from navigation start, and the `web-vitals` library exposes it as `onTTFB`. Google's guidance is 800 ms or less at p75 for good, and over 1,800 ms for poor.
Break it into pieces in the Network panel's Timing tab: queueing, DNS, initial connection, SSL, request sent, and waiting. The waiting phase is the server's time, and the earlier phases are network.
Worked example
A WooCommerce store on shared hosting shows a TTFB of 1.9 s on its product page. The Timing tab reads DNS 40 ms, connect and SSL 190 ms, and waiting 1,640 ms. Query Monitor shows 212 database queries.
After enabling a page cache plugin and Redis object cache, waiting falls to 160 ms and TTFB to 420 ms. LCP moves from 4.6 s to 2.8 s with no frontend change.
How it differs
TTFB is about the first byte; page speed is about when the page is usable. A low TTFB does not make a fast page, because a quick first byte can precede 4 MB of script. A high TTFB does set a floor, since LCP can never come earlier than it.
Common errors
Testing from the same city as the server. Measuring with a warm cache. Leaving redirects out of the count. Confusing TTFB with server response time. Treating a CDN edge's TTFB as origin speed. Comparing a lab number with p75 field data.
In practice
Check TTFB for your top five URLs from two regions, with caching on and off. If the waiting phase dominates, look at page caching, slow queries, and cold starts. If connect and SSL dominate, look at CDN coverage and HTTP/3. Re-measure from field data after a week.