Time to first byte

Also called TTFB, server response time

The time between sending a request and receiving the first byte of the response. It covers DNS resolution, the TCP and TLS handshakes, the request travelling to the origin, the server doing its work, and the first byte travelling back.

That list is worth keeping in mind, because most of it is network and only one part is your application. A 900ms TTFB on a site whose server renders in 40ms is a connection problem, not a code problem, and profiling the application will find nothing.

The mistake

Optimizing it as a ranking factor. It is not one, directly, and chasing it for that reason leads to work with no payoff.

What it does affect is crawling. Crawl rate responds to how your server behaves, so a slow or erratic origin gets fetched less often, and the effect outlasts the slowness. A site recovering from an outage often sees crawl volume stay low for days after the server is fine. That is a crawl budget consequence, and on a large site it is the difference between new pages being found this week or next month.

It also compounds with everything else on the page. Nothing renders before the first byte arrives, so a slow TTFB shifts every user-visible timing by the same amount, and no amount of front-end work recovers it.

Measure the tail, not the average. Crawlers and users both experience the slow requests, and a median of 200ms with a p95 of 4 seconds is a worse site than a flat 500ms. The pattern to look for is a TTFB that degrades under load, because that is the one that turns into 503 responses and a 429 rate limit when a crawler arrives in volume.

Caching at the edge is the usual fix and prerendering is the usual way to make caching possible, since a page built per request for a logged-out visitor is work nobody asked for.