Understanding TTFB (Time to First Byte) and Why It's Slowing Your Site

Time to First Byte measures how long it takes for a visitor's browser to receive the very first byte of response data after making a request — before any actual content has even begun rendering. A slow TTFB delays everything downstream, including your other Core Web Vitals. Here's what actually causes it and how to fix it.

Why TTFB Sits Upstream of Everything Else

Think of TTFB as the foundation your entire page load is built on. Before the browser can start parsing HTML, discovering CSS and JavaScript to fetch, or rendering your Largest Contentful Paint element, it needs that first byte of the response. A slow TTFB pushes back the start of every subsequent step in the loading process — even a perfectly optimized frontend can't compensate for a server that takes 3 seconds just to begin responding.

Google recommends TTFB under 800 milliseconds, with under 200ms considered excellent.

What Actually Happens During TTFB

TTFB encompasses several sequential steps: DNS lookup, TCP connection establishment, TLS negotiation (for HTTPS), the server processing your actual request, and finally the first byte being sent back. A slowdown in any one of these steps adds directly to your total TTFB.

Common Causes and Fixes

Slow DNS resolution. If your DNS provider is slow to resolve, this adds delay before the browser can even begin connecting. Using a fast, reliable DNS provider (many CDN providers include this) can shave meaningful time off here.

Unoptimized database queries. If your server has to run expensive database queries before it can generate the response, this directly delays TTFB. This connects back to database indexing — a missing index that turns a 20ms query into a 2-second query has an enormous direct impact on TTFB.

No caching layer. Without page or object caching, every single request triggers full page generation from scratch — running all the same expensive logic and queries repeatedly for identical content that could have been served from cache instantly.

Under-resourced server. If your server is consistently under memory or CPU pressure, request processing slows down across the board, directly impacting TTFB along with everything else.

Physical distance between server and visitor. The further the round trip between visitor and origin server, the more latency accumulates in the connection establishment steps alone, before your server even begins processing the actual request. This is where a CDN with edge caching helps enormously, since cached content can be served from a nearby edge location without hitting your distant origin server at all.

Inefficient application code. Slow application-level logic — inefficient loops, unnecessary API calls made synchronously before responding, poorly optimized template rendering — all add directly to server processing time.

How to Measure TTFB Accurately

Chrome DevTools' Network tab shows TTFB for any request directly (look at the timing breakdown for the initial document request). Google PageSpeed Insights and other web performance tools also report it explicitly. For ongoing tracking, real-user monitoring data gives a more complete picture than a single lab test, since TTFB can vary based on server load at different times of day.

Server-Side Rendering vs Static Generation Considerations

If you're using a server-side rendering framework, every request potentially triggers fresh rendering work, directly impacting TTFB under load. Where content doesn't need to be generated fresh on every single request, static site generation or aggressive page caching can effectively eliminate this rendering cost entirely for most visitors, serving pre-built or cached HTML instead.

The Compounding Effect on Other Metrics

Because TTFB happens before anything else, a slow TTFB doesn't just hurt its own metric — it pushes back your entire loading timeline. A page with excellent frontend optimization but a 2-second TTFB will still have a poor LCP score, simply because LCP can't begin until after that slow first byte arrives. This is why TTFB deserves attention even though it's not itself one of the three official Core Web Vitals — fixing it often improves your other scores as a side effect.

The Bottom Line

TTFB is fundamentally a backend and infrastructure problem, not a frontend one — no amount of image compression or JavaScript optimization will fix a slow server response. Database optimization, proper caching, adequate server resources, and reducing physical distance via a CDN are the actual levers that move this metric, and improving it tends to have a compounding positive effect on everything measured downstream.