Time to First Byte(TTFB)

Long definition

TTFB is the first measurable signal of perceived speed. Until that first byte arrives, the browser cannot parse HTML, discover subresources, or render anything. Every metric downstream — FCP, LCP, Speed Index — inherits whatever TTFB you ship.

The number bundles five distinct steps: DNS resolution, TCP handshake, TLS handshake, request queueing on the server, and backend processing time. A slow TTFB rarely points at one of these in isolation — it's usually a combination, which is why "fix TTFB" projects often touch CDN config, origin response time, and connection setup at once.

Google publishes TTFB as a diagnostic metric on web.dev rather than a Core Web Vital. It does not rank pages directly on TTFB, but it gates LCP: a 1.5s TTFB makes a sub-2.5s LCP nearly impossible. If your LCP is poor in field data, TTFB is the first thing to inspect.

Field thresholds (75th percentile of CrUX data):

• Good — under 800ms
• Needs improvement — 800ms to 1800ms
• Poor — above 1800ms

Common levers, in order of impact for typical sites: CDN with edge caching for HTML, faster origin (database query budget, server-side rendering caching), HTTP/2 or HTTP/3 with connection coalescing, geographically closer origin, eliminating server-side redirects on the navigation request.

Common misconceptions

• "TTFB is just server response time." Server processing is one of five components. A site with a 50ms backend can still ship a 1200ms TTFB if DNS, TCP, and TLS each cost 200-400ms on a cold connection from a distant region.
• "TTFB doesn't matter — only Core Web Vitals do." TTFB is upstream of LCP. Google ranks on LCP, but a poor TTFB makes a good LCP impossible. Optimizing one without the other is wasted effort.
• "Caching the HTML at the CDN solves TTFB." It solves it for cached requests. The first request after a cache purge, the long-tail URL nobody visits, and any logged-in user bypassing the cache still hit the origin.