Aprender
TTFB: What It Measures and How to Reduce It
TTFB is everything that happens before your page starts arriving. It is not a Core Web Vital, and it sets the floor that every Core Web Vital has to clear.
Ejecuta una auditoría nueva en DomainLens y usa el informe como lista de prioridades.
What TTFB actually includes
Time to First Byte measures from the start of navigation to the arrival of the response's first byte. That covers far more than server processing: redirects, DNS resolution, TCP connection, TLS handshake, the request itself, and only then the server thinking about it.
This matters for diagnosis because "slow TTFB" is usually read as "slow backend" when a third of it can be connection setup, and a redirect chain can double it before the real server is even contacted.
| Phase | Typical share | Fixed by |
|---|---|---|
| Redirects | 0 or a lot | Removing hops |
| DNS lookup | Small, unless cold | A faster DNS provider |
| TCP + TLS | Meaningful on distance | A CDN closer to the user |
| Server processing | Often the largest | Caching, queries, code |
| Response start | Small | Streaming the response |
What counts as good
Google suggests keeping TTFB under 800 milliseconds, with under 200 as an ideal for the server portion. Those are guidance rather than a threshold you pass or fail, because TTFB is not itself a Core Web Vital.
It matters because it is a floor. LCP cannot be faster than TTFB plus the time to fetch and render the largest element — so a 1.5-second TTFB makes a good LCP arithmetically impossible no matter what you do to images.
Measuring it properly
- 1Measure from several locations, not just your own — TTFB is dominated by distance for users far from your origin.
- 2Measure a cold request and a warm one; a cached response and an uncached one are different measurements of different things.
- 3Separate the phases rather than reading one number, so you know whether to look at the network or the application.
- 4Compare a static asset against a dynamic page; if the static file is fast and the page is slow, the application is the constraint.
- 5Check field data too — your own connection is not representative of your visitors.
curl -o /dev/null -s -w '\
dns: %{time_namelookup}s\n\
connect: %{time_connect}s\n\
tls: %{time_appconnect}s\n\
ttfb: %{time_starttransfer}s\n\
total: %{time_total}s\n\
redirects:%{num_connects}\n' \
https://example.com/
# A large gap between tls and ttfb is server processing.
# A large connect or tls value is distance or handshake cost.The fixes, in order of usual impact
The first two account for most real-world improvement. Application profiling is satisfying and frequently unnecessary once a page cache is in place.
- Remove redirect hops. Each one is a full round trip before anything begins, and chains of three are common.
- Cache full pages. Serving a cached HTML response turns application time into near zero, and it is the single largest win on most dynamic sites.
- Put a CDN in front, so connection setup happens near the user rather than across an ocean.
- Fix the slow query. On uncacheable pages this is usually one query or one uncached external API call.
- Keep connections alive and enable HTTP/2 so repeated requests skip handshake cost.
When TTFB is fine and the page is still slow
A fast first byte followed by a slow page means the constraint moved to rendering: blocking scripts, late-discovered images, or a client-side render that starts only after the bundle arrives. That is a different investigation entirely — see what LCP measures and gzip vs brotli for the transfer side.
How DomainLens contributes
DomainLens reports TTFB alongside the redirect chain and the Core Web Vitals, which is the combination that identifies the cause — a slow first byte next to a three-hop redirect is a different problem from a slow first byte on a direct request. See the Core Web Vitals guide for what TTFB is capping.
- Is TTFB a ranking factor?
- Not directly, and it is not a Core Web Vital. It matters because it sets the floor for LCP, which is.
- What is a good TTFB?
- Under 800ms as general guidance, with under 200ms for the server portion as an ideal. Treat them as targets rather than pass marks.
- Does a CDN fix TTFB?
- It fixes the connection and distance portion, and for cached responses it fixes almost all of it. It does nothing for slow application processing on an uncacheable page.
- Why is my TTFB high only for some users?
- Distance from your origin, almost always. Users far from the server pay more connection setup, which is exactly what a CDN addresses.