The time between initiating a resource request and receiving the first response byte.
Time to First Byte measures the wait before the beginning of a response arrives. For a page navigation, this happens before the browser can use the main HTML response to build the page. It is an early delivery measurement, not the time when the visitor sees the completed page or can successfully use every control.
TTFB can include more than server application processing. Connection setup, network travel, redirects and other request-handling stages can contribute. That makes it a useful starting point for diagnosis, but not automatic proof that a hosting plan is inadequate. The measurement’s scope and the request involved matter when comparing tools or environments.
A quick first byte does not guarantee quick rendering. After receiving it, the browser may still need the rest of the document, styles, images and scripts. Conversely, a long initial wait can delay everything that follows. Keep TTFB separate from contentful-paint metrics so a developer can distinguish response delivery from the work needed to display useful content.
Takeaway: Use TTFB to locate an early delay, then investigate its cause before changing providers or buying additional infrastructure. Ask what part of the request timeline is slow.
Example
A repair company notices that one appointment page waits much longer than its other pages before beginning to load. A developer compares the request timelines and checks the page’s processing and redirect path. That evidence is more useful than assuming the entire website needs a new theme.
What to check
Compare the same URL under documented conditions, including whether the response was cached and where the test ran. A cached response and a newly generated response may have different work behind them. Keep private or personalized pages out of blanket caching changes unless the implementation safely supports them.
For more detail, see Web.dev TTFB guide.