Time to First Byte (TTFB)
How long from the click until the very first byte of HTML comes back. Everything else has to wait for it. Aim under 800ms.
See it
What it is
TTFB is the stopwatch from clicking a link to the first byte of the HTML response arriving. It bundles redirects, DNS lookup, TCP and TLS handshakes, the request itself, and however long your server took to think. Under 800ms is the usual good bar, over 1.8s is bad.
It matters because it is the floor under everything else. FCP and LCP cannot happen before the first byte lands, so a 1.5s TTFB means you are already spending most of a 2.5s LCP budget doing nothing visible. The big wins are structural: cache HTML at a CDN edge, use stale-while-revalidate so the slow path never faces a user, kill redirect chains, fix the N+1 query, and stream the HTML so the head flushes before the slow data resolves.
Gotcha: TTFB is a diagnostic, not a Core Web Vital, and a great TTFB proves nothing on its own. A page can answer in 80ms and still take six seconds to show anything if the HTML is an empty div waiting on a JS bundle. Also, measuring from your own machine with a warm cache flatters you; real users are cold, far away, and on mobile networks.
Ask AI for it
Cut this page's Time to First Byte to under 800ms. Trace where the time goes (redirects, DNS, TLS, server processing) and then: remove redirect chains so the first request is the final URL, cache the HTML response at the CDN edge with Cache-Control plus stale-while-revalidate, add preconnect for any origin needed early, stream the HTML so the <head> flushes before slow data resolves, and move blocking data fetches out of the critical path or behind a cache. On the server, profile the request handler and fix the unindexed or N+1 queries. Report the before/after breakdown per phase.