Time to First Byte (TTFB)
Time to First Byte is the duration from a user requesting a page to the first byte of response arriving in their browser. TTFB is a supporting performance metric (not a Core Web Vital itself) but directly affects LCP — a slow TTFB pushes LCP later. Good TTFB target: under 200ms; under 100ms is excellent.
Also called: TTFB, Server response time · Last updated: May 27, 2026 · By Joseph W. Anady
Why it matters.
TTFB is the server-side latency component of page load. It measures the time from the user's request leaving their browser to the first byte of response data arriving. If TTFB is 800ms, every other performance metric starts 800ms later — LCP gets pushed past the 2.5 second threshold, INP becomes harder to maintain, the perceived page speed suffers. TTFB optimization is foundational performance work.
How it works.
TTFB combines several latencies: DNS resolution, TCP handshake, TLS handshake, server processing, and first-byte response. Each component can be measured independently. Bottlenecks usually appear in server processing (database queries, render time, third-party API calls during render) or server location (geographically distant users see higher TTFB).
2026 reality check.
TTFB matters more in 2026 because of the cascade effect: slow TTFB pushes LCP into 'Needs Improvement' territory even on otherwise-optimized pages. WordPress hosts on shared hosting routinely measure TTFB at 600-1500ms — they cannot pass Core Web Vitals regardless of other optimizations. Custom hand-coded sites on direct Linux hosting (TDG's pattern) measure TTFB at 30-100ms.
Data points
- Good TTFB target: <200ms (Google PageSpeed guidance)
- Excellent TTFB: <100ms
- Above 600ms makes LCP <=2.5s very difficult
- Components: DNS + TCP + TLS + server processing + first-byte response
- WordPress shared hosting typical TTFB: 400-1500ms
First-hand insight from ThatDeveloperGuy.
ThatDeveloperGuy hosts all client sites on bare-metal Debian Linux infrastructure under direct administrative control, served by nginx with HTTP/2 and HTTP/3. Static HTML responses ship from nginx without involving any application server — TTFB consistently under 100ms for US-based users. Sites with server-side logic use cached responses where possible. We deliberately avoid Cloudflare proxy (adds 50-200ms TLS handshake for non-cached responses) and Vercel/Netlify (adds platform routing overhead).
How TDG approaches it
TDG's TTFB stack: bare-metal Debian Linux, nginx serving static HTML directly, no app-server-in-the-loop for static pages, FastAPI for dynamic endpoints with caching, no Cloudflare, no Vercel, no Netlify, geographic distribution via direct DNS routing where needed. Result: 30-100ms TTFB consistent.
Common mistakes.
- Using shared WordPress hosting with multi-tenant PHP-FPM (TTFB usually 400-1500ms)
- Layering Cloudflare on top of slow origin (caches successful requests but doesn't fix TTFB for cache misses)
- Server-side rendering with no caching (every request hits the database)
- Third-party API calls during server render (each API call adds 50-500ms to TTFB)
- Geographically distant hosting (US users on EU servers see 100-200ms baseline TTFB)
FAQ.
Is TTFB a Core Web Vital?
No — TTFB is a supporting performance metric. Google's CWV are LCP, INP, CLS. But TTFB directly affects LCP, so optimizing TTFB is foundational for CWV success.
What's a good TTFB?
Under 200ms is good. Under 100ms is excellent. Above 600ms makes LCP very hard to pass. Above 1000ms is 'broken' territory.
Does Cloudflare improve TTFB?
For cached responses, yes — edge caching can push TTFB to <50ms. For uncached requests, Cloudflare adds 50-200ms vs direct origin. Net effect depends on cache hit rate.
How do I measure TTFB?
PageSpeed Insights shows TTFB. Chrome DevTools Network tab shows TTFB per request. WebPageTest.org provides detailed TTFB waterfall.
Does TTFB affect SEO?
Indirectly via LCP — slow TTFB makes LCP harder to pass. Google has confirmed Page Experience signal includes responsiveness, but TTFB itself isn't a direct ranking factor.
Maintained by Joseph W. Anady at ThatDeveloperGuy. Back to glossary · Suggest a term