TTFB (Time to First Byte)
TTFB measures the time from navigation request until the first byte of the server response arrives. Target: under 800 ms.
Definition
TTFB is a connection-level metric reflecting DNS, TCP/TLS handshake, server processing, and network latency. While not a Core Web Vital itself, it is critical because every millisecond of TTFB directly pushes LCP and FCP later.
What Contributes
Redirects, DNS lookup, TCP connection, TLS negotiation, and server response generation. On a fast CDN-cached page, TTFB should be under 200 ms.
Common Misunderstandings
Not just server time. Network distance adds base latency (Singapore to London = 150+ ms). Includes redirect hops. Lab TTFB often misses redirect costs.
Optimization
Use a CDN with edge caching. Implement full-page caching. Optimize backend queries. Use in-memory caching (Redis). Eliminate unnecessary redirects. Preconnect to origins.
Note
In code
<link rel="preconnect" href="https://cdn.example.com">
# Server-Timing: db;dur=53, cache;dur=22, render;dur=89Common questions
- Q. Does a CDN always improve TTFB?
- A. Yes for static cached content. For dynamic content, the CDN adds a network hop to origin.
Thresholds
| Rating | TTFB Threshold |
|---|---|
| Good | ≤ 800 ms |
| Needs Improvement | 800 ms - 1.8 s |
| Poor | > 1.8 s |
Key takeaways
- Time until first byte of response.
- Target: ≤ 800 ms (under 200 ms excellent).
- Not a CWV but gates LCP and FCP.
- Includes redirects, DNS, TCP/TLS, server processing.
At a glance
- Measures
- Server delay
- Target
- ≤ 800 ms
- Part of
- Diagnostic
- Type
- Field & Lab
How Atomic Glue helps
Atomic Glue reduces TTFB through CDN deployment, caching, and backend optimization. Web Development services.
Get in touchUnderlined terms have their own entry. Selecting one shows it on the map below.
Atomic Glue. "TTFB (Time to First Byte)." Glossary.atomicglue.co/glossary/ttfb-time-to-first-byte
How TTFB (Time to First Byte) connects
TTFB measures the time from navigation request until the first byte of the server response arrives. Target: under 800 ms.
Definition
TTFB is a connection-level metric reflecting DNS, TCP/TLS handshake, server processing, and network latency. While not a Core Web Vital itself, it is critical because every millisecond of TTFB directly pushes LCP and FCP later.
What Contributes
Redirects, DNS lookup, TCP connection, TLS negotiation, and server response generation. On a fast CDN-cached page, TTFB should be under 200 ms.
Common Misunderstandings
Not just server time. Network distance adds base latency (Singapore to London = 150+ ms). Includes redirect hops. Lab TTFB often misses redirect costs.
Optimization
Use a CDN with edge caching. Implement full-page caching. Optimize backend queries. Use in-memory caching (Redis). Eliminate unnecessary redirects. Preconnect to origins.
Note
Diagnostic metric. Google suggests 800 ms as reasonable. Aim for under 200 ms for competitive performance.
In code
<link rel="preconnect" href="https://cdn.example.com">
# Server-Timing: db;dur=53, cache;dur=22, render;dur=89
Common questions
Q: Does a CDN always improve TTFB?
A: Yes for static cached content. For dynamic content, the CDN adds a network hop to origin.
Thresholds
Rating: Good, TTFB Threshold: ≤ 800 ms
Rating: Needs Improvement, TTFB Threshold: 800 ms - 1.8 s
Rating: Poor, TTFB Threshold: > 1.8 s
Key takeaways:
Time until first byte of response.
Target: ≤ 800 ms (under 200 ms excellent).
Not a CWV but gates LCP and FCP.
Includes redirects, DNS, TCP/TLS, server processing.