Time to First Byte (TTFB)
Time to First Byte is how long from a request until the first byte of the response arrives: it captures DNS, connection, and server processing, and sets the floor for every page-load metric after it.
also: TTFB · time to first byte
TTFB sums everything before the response starts: DNS lookup, the TCP and TLS handshake, the request travelling to the server, the server doing its work, and the first byte travelling back. Nothing on the page can render until it lands, so a slow TTFB pushes back First Contentful Paint and Largest Contentful Paint by the same amount, no matter how lean your frontend is.
Because it is mostly backend and network, TTFB is where caching and edge delivery pay off. Serving from a CDN edge cuts the round-trip distance; caching the rendered response removes the server work entirely. Google treats a TTFB under about 800ms as good; consistently above that and the problem is almost always origin processing or distance, not the browser.
faq
Questions & answers
- What is a good TTFB?
- Under about 800ms at the 75th percentile is Google's 'good' threshold; under 200ms is excellent and usually means you are serving from cache or an edge. Above 800ms points at origin processing time or network distance.
- How do I improve TTFB?
- Cache the response so the server does less work, serve from a CDN edge to cut distance, speed up the slow database queries and backend work behind the request, and keep connections warm. TTFB is mostly a backend and network problem, not a frontend one.
Want this applied to your stack, not just defined?
The free tools run the numbers; an audit tells you where the real cost and risk are. Book a call, or leave your email and I'll reach out.
Prefer proof first? See how this plays out in real case studies →