How Do You Reduce Time to First Byte?
TTFB is not itself a Core Web Vital, which causes it to be neglected. It nevertheless sets the floor for every metric that follows: nothing can render before the document arrives, so a slow TTFB caps how good LCP can possibly be no matter what you do afterwards.
What actually happens during TTFB?
DNS resolution, TCP connection, TLS negotiation, the request travelling to the server, the server generating a response, and the first byte travelling back. Server processing is often the largest component on dynamic sites, but on distant origins network round trips can dominate.
Splitting the measurement matters because the fixes differ. If connection setup dominates, a CDN with edge termination helps most. If server processing dominates, no amount of network optimisation will help and the work belongs in the application.
What is a good TTFB target?
Below 800 milliseconds is the commonly cited good threshold, with under 200 milliseconds achievable for cached static responses served from an edge. Above roughly 1.8 seconds, passing LCP becomes very difficult because too little of the 2.5-second budget remains.
Treat it as a budget rather than a score. If LCP must land within 2.5 seconds and TTFB consumes 1.2 of them, everything else, connection to image resources, render-blocking CSS, the image download, must complete in 1.3 seconds. Framed that way the priority becomes obvious.
What are the highest-yield fixes?
Cache the full HTML response where the page permits it, since serving from cache removes application work entirely. Put a CDN in front of the origin so connections terminate near the user. Profile and fix slow database queries. Remove redirect chains, each of which adds a full round trip.
Full-page caching is the change most often dismissed as impossible and most often achievable in some form. Even pages with personalised elements can usually cache the shell and fill the personal parts client-side, which converts a database-bound response into a static one.
Do redirects matter that much?
More than people expect. Each redirect adds a full request and response cycle before the real document is even requested, and chains of two or three are common on sites that have accumulated URL changes. On mobile networks a single redirect can add several hundred milliseconds.
The frequent offenders are HTTP to HTTPS, non-www to www, trailing-slash normalisation and legacy URL migrations, applied in sequence. Collapsing them so any entry URL reaches its destination in one hop is usually a configuration change rather than an engineering project.
Key takeaways
- TTFB sets the floor for LCP; front-end work cannot recover time lost before the document arrives.
- Target below 800 milliseconds, with under 200 achievable for edge-cached responses.
- Split the measurement: connection setup and server processing need different fixes.
- Full-page caching is the highest-yield change and is more often possible than assumed.
- Each redirect adds a full round trip; collapse chains to a single hop.
Frequently asked questions
- Is TTFB a Core Web Vital?
- No. It is a diagnostic metric rather than one of the three assessed vitals. Google documents it as a supporting measurement because it strongly influences LCP. Failing TTFB does not fail the assessment directly, but it very often causes the LCP failure that does.
- Does HTTP/2 or HTTP/3 improve TTFB?
- Modestly. HTTP/3 reduces connection setup latency, which helps most on high-latency mobile networks. Neither changes server processing time, so on a site whose TTFB is dominated by slow application code the protocol upgrade produces little visible improvement.
- Why is TTFB worse for some visitors?
- Distance to the origin and network quality vary by location, so visitors far from your server see longer round trips. Cache state also matters: an uncached first visitor triggers full application work while a later visitor may be served from an edge cache in a fraction of the time.
- Does shared hosting cause slow TTFB?
- It often contributes, because CPU and disk are contended with other tenants and response times become inconsistent. Look at variance as well as the average; erratic TTFB across repeated tests on the same page is a strong hint that the constraint is the hosting environment.
Web Performance, BigBalli. We track Core Web Vitals definitions and thresholds as Google revises them, cross-checked against web.dev and Chrome developer documentation.