Time to First Byte (TTFB): Definition, Causes, Optimization

What is Time to First Byte (TTFB)?

Time to First Byte (TTFB) is the time it takes for the browser to receive the first byte of an HTTP response after sending the request. It captures everything that happens before any rendering can start: DNS lookup, TCP handshake, TLS negotiation, server processing, database queries, and the network round-trip.

TTFB is foundational for perceived performance — every subsequent metric (LCP, FCP, TTI) is bounded by it. If your TTFB is 2 seconds, your LCP can never be under 2 seconds, no matter how fast your frontend is. It's also a Web Vital diagnostic metric (not a Core Web Vital but recommended to track).

TTFB phases — what's actually happening in those milliseconds

Total TTFB ≈ DNS + TCP + TLS + (app processing) + RTT. Server-side processing is the variable that matters most.

TTFB thresholds

Per Google's recommendations. Note: these are at the 75th percentile of users.

How to measure TTFB

JavaScript API

// PerformanceNavigationTiming gives you TTFB
new PerformanceObserver((list) => {
  for (const entry of list.getEntriesByType('navigation')) {
    const ttfb = entry.responseStart - entry.requestStart;
    console.log('TTFB:', ttfb, 'ms');
  }
}).observe({ type: 'navigation', buffered: true });

cURL

curl -w "@-" -o /dev/null -s https://example.com <<EOF
  time_namelookup:  %{time_namelookup}\n
  time_connect:     %{time_connect}\n
  time_appconnect:  %{time_appconnect}\n
  time_starttransfer: %{time_starttransfer}\n
  time_total:       %{time_total}\n
EOF

time_starttransfer ≈ TTFB.

Tools

Common TTFB optimizations

1. Add a CDN with edge caching

For static + cacheable HTML, edge servers respond from RAM in < 50ms regardless of origin location. Single biggest TTFB win.

2. Cache the dynamic HTML

Server-rendered pages can often be cached for 60s-5min at the CDN. Cache-Control: s-maxage=300 on responses.

3. Optimize database queries

Slow N+1 queries are the #1 server-side TTFB killer. Add indexes, use eager loading, profile queries with EXPLAIN.

4. Use HTTP/2 or HTTP/3

Eliminates head-of-line blocking + multiple connection overhead. HTTP/3 over QUIC handles packet loss better.

5. TLS 1.3 for faster handshake

1 RTT instead of 2 for new connections, 0 RTT for resumed sessions.

6. Connection reuse

Keep-alive + HTTP/2 multiplexing reuses a single connection for many requests, eliminating handshake overhead.

7. Geo-distributed origins

If your origin is in us-east-1 but users are in Sydney, network alone is 200ms+. Multi-region deployment or edge functions help.

8. Pre-render or static generate where possible

If a page doesn't NEED to be dynamic, generate it at build time and serve as static HTML. TTFB drops to whatever your CDN returns.

TTFB and Core Web Vitals

TTFB isn't a Core Web Vital itself, but it directly affects LCP:

• LCP starts measuring from request, so TTFB is included in LCP
• If TTFB is 1s, LCP is at least 1s before any rendering can happen
• Improving TTFB by 500ms typically improves LCP by ~500ms

Watch TTFB even though it's diagnostic — it's the foundation everything else builds on.

Common TTFB pitfalls

• Origin in one region, users worldwide. Network latency dominates.
• Server-side rendering without caching. Every request re-renders.
• N+1 database queries. Each query adds 5-50ms; loops compound.
• Synchronous external API calls. Page render waits for slow third-party.
• Cold-start serverless functions. First-request TTFB is multi-second.
• Heavy middleware (auth, rate limit, logging). Adds tens of ms per request.
• TLS resumption disabled. Every connection re-negotiates.
• HTTP/1.1 only. Head-of-line blocking + connection limits.

FAQ: Time to First Byte

What's a good TTFB?

≤ 800ms at 75th percentile per Google. Sub-200ms is achievable with edge-cached static content; sub-500ms is great for dynamic SSR.

Is TTFB a Core Web Vital?

No — INP, LCP, and CLS are. But TTFB is recommended diagnostic metric and directly caps LCP.

How does CDN improve TTFB?

Edge servers cache responses close to users (sub-50ms RTT vs 100-300ms to origin). For cacheable content, TTFB drops by 100-500ms.

Why is my TTFB different on lab vs field?

Lab tests use controlled networks; field measures real users with varied connections, geographies, devices. Lab usually optimistic.

Does HTTPS hurt TTFB?

Slightly — TLS adds ~1-2 RTTs on first connect. But TLS 1.3 + connection reuse + HTTP/2 minimize the cost. The performance gap vs HTTP is small enough that always-HTTPS is correct.

How do I improve TTFB on a dynamic page?

Cache at the CDN with short s-maxage. Optimize DB queries. Move to edge SSR (Vercel Edge, Cloudflare Workers). Pre-render where possible.

What's the difference between TTFB and Server Response Time?

Server Response Time = just the app/DB phase. TTFB = network + app phase. Network is often a meaningful chunk for far-away users.

Test TTFB from real regions with LoadFocus

LoadFocus runs Lighthouse + load tests from 25+ global regions, surfacing how TTFB varies by geography. Sign up free at loadfocus.com/signup.