TTFB and Server Timing

Diagnose Time to First Byte with Navigation Timing and break down backend phases via Server-Timing.

intermediate3 min readUpdated Aug 4, 2026

performance
ttfb
server-timing
cdn
lcp

TTFB is how long until the browser receives the first byte of the document (or resource) response. Bad TTFB delays everything on the critical path — including LCP. Frontend can’t fix a 2s origin, but can diagnose, cache, and push work to the edge.

Docs: web.dev TTFB, MDN Server-Timing, Navigation Timing.

Measure document TTFB

const [nav] = performance.getEntriesByType('navigation');
const ttfb = nav.responseStart - nav.requestStart;
// some tools use responseStart - startTime (includes redirects)
console.log({ ttfb, protocol: nav.nextHopProtocol, type: nav.type });

Field: onTTFB from web-vitals. Thresholds: many guides treat ≤800ms as good for documents — confirm current web.dev guidance for your goals.

What’s inside TTFB

redirects + service worker + DNS + connect + TLS + request queue + server work + network to first byte

Segment with:

CDN logs
Server-Timing
Synthetic tests from multiple regions

Server-Timing header

Server-Timing: cache;desc="HIT", db;dur=12.3, render;dur=48.0

const [nav] = performance.getEntriesByType('navigation');
console.log(nav.serverTiming);
// [{ name: 'db', duration: 12.3, description: '' }, ...]

Expose only non-sensitive timings. Great for correlating “SSR render” vs “auth” vs “DB.”

Frontend-adjacent fixes

Problem	Lever
Cold origin far from user	CDN / edge SSR / static generation
HTML uncacheable personalized	Edge cache with vary keys; stream shell
Heavy SSR compute	Cache fragments; reduce work per request
Redirect chains	Flatten absolute URLs
SW boot delay	Optimize SW install path

Streaming HTML can improve perceived start even when final TTFB-ish metrics vary — still measure.

LCP connection

LCP ≥ document TTFB + resource delay + download + render delay. If TTFB is 1.8s, LCP cannot be “good” on that navigation. Fix origin before micro-optimizing hero quality.

Interview out-loud

“TTFB is time to first byte of the response; I read it from Navigation Timing and split backend phases with Server-Timing. Fixes are CDN, caching, slimmer SSR, and fewer redirects — frontend UI tweaks can’t outrun a multi-second origin.”

How this shows up in interviews

Be ready to define the metric or technique in one sentence, name one measurement approach (DevTools panel, web-vitals, or headers), and cite a concrete fix you would try first. Walk through a before/after: what the waterfall or flame chart showed, what you changed, and which percentile moved. Mention a tradeoff (complexity, caching correctness, or third-party business constraints) so the answer doesn’t sound like a blog checklist.

Production guardrails

Ship behind a flag when the change is risky, watch field p75 for the affected template for at least a few days, and keep a rollback path. Pair lab verification (throttled Performance/Network) with RUM so you don’t celebrate a Lighthouse-only win. Document the owner of any ongoing budget or third-party exception.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.