Time to First Byte

TTFB is a diagnostic metric, not one of the three Core Web Vitals (LCP, INP, CLS). Google does not rank pages on TTFB directly. It matters because it sits in front of everything the user sees: First Contentful Paint and Largest Contentful Paint cannot begin until that first byte lands, so a slow response pushes every downstream paint metric later.

Google’s thresholds, measured at the 75th percentile of real users:

• Good: 800 ms or less
• Needs improvement: 800 ms to 1,800 ms
• Poor: over 1,800 ms

The number bundles several stages: redirect time, DNS lookup, connection and TLS negotiation, then the server’s own work before it flushes the first byte. So TTFB is part network, part backend. Cutting it usually comes down to hosting that can handle your load, a CDN that terminates connections near the user, sensible Cache-Control headers, and killing same-origin redirect chains (an HSTS preload entry removes the HTTP-to-HTTPS hop on first visit).

Good TTFB is a floor, not a ceiling

Cloudflare’s data adds an important caveat: a poor TTFB reliably predicts a poor experience, but a good one does not guarantee it. In their analysis, roughly 21% of pages under the 800 ms mark still had poor LCP. Tricks like 103 Early Hints can even lower the TTFB clock without making the page usable any sooner. Treat TTFB as the first thing to fix, not the finish line.