Glossary
TTFB (Time to First Byte)
TTFB is the time between the browser sending an HTTP request and receiving the first byte of the response. It measures server / network responsiveness, separately from rendering.
Time to First Byte measures how long it takes for the browser to receive the first byte of HTML from the server after sending a request. It's an early-stage metric that captures DNS resolution, TCP/SSL handshake, network round-trip, and server response generation — everything BEFORE the browser starts rendering.
Good TTFB targets: under 200ms for static content, under 600ms for dynamic content. Anything over 1,000ms is a problem and signals server or network bottlenecks. Google's PageSpeed Insights flags TTFB explicitly because it's a foundational signal — every other speed metric (LCP, FCP) is gated by TTFB.
What slows TTFB: a server geographically far from the user (no CDN), an underpowered server (small DigitalOcean droplet, free-tier Heroku), database queries on every request (no caching), and uncompressed transfer (no Brotli / gzip). The 80/20 wins are: use a CDN with edge servers, cache rendered HTML, use HTTP/2 or HTTP/3, and enable Brotli compression.
TTFB is NOT a Core Web Vital itself but feeds directly into LCP and FCP. Improving TTFB by 200ms typically improves LCP by a similar amount. The cheapest TTFB win is putting a CDN (Cloudflare, Fastly, or your hosting platform's edge network) in front of your origin server.
Example
A blog hosted on a single $5 DigitalOcean droplet in New York has TTFB of 1,200ms for visitors in Tokyo. Putting Cloudflare in front (caching static HTML at the edge) drops TTFB for Tokyo visitors to 80ms — LCP improves from 4.2s to 1.8s with no other changes.