Time to First Byte (TTFB)

Time to First Byte is the time from the start of the navigation to the first byte of the response. Google calls 800 ms or less good, at the 75th percentile of real page loads. Over 1.8 seconds is poor. TTFB isn't a Core Web Vital. It still sits under every metric that is. Nothing paints before the first byte arrives, and that includes the largest paint on the page.

The definition is the easy part. Tools disagree about where the clock starts. One of our own runs came back as both 306 ms and 1,098 ms, for one page load.

What's inside TTFB

Everything the browser does before the response begins:

• redirects on the entry URL
• service worker startup, if the page registers one
• the DNS lookup
• the TCP connection and the TLS handshake
• the request itself, until the first response byte lands

In a browser, one line reads it:

performance.getEntriesByType("navigation")[0].responseStart

There's one catch. On a site that sends 103 Early Hints, responseStart marks the interim response rather than the real one. Use finalResponseHeadersStart where the browser supports it.

Why does Lighthouse report a smaller number?

Because Lighthouse doesn't report TTFB at all. It reports initial server response time, and that audit computes receiveHeadersStart − sendEnd on the main document. The clock starts after the connection is up and the request went out. Redirects, DNS and the handshake all fall outside it. Chrome's documentation for the audit lists the same two exclusions: DNS lookups and redirects.

Two things follow from the narrower definition:

• The threshold is 600 ms, not 800 ms. The source explains the odd figure: DevTools throttling can't see a response faster than about 570 ms, so 600 ms avoids false positives. The number it tells you to aim for is 100 ms.
• It carries no weight in the performance score. It's a diagnostic, and it reports an estimated FCP and LCP saving of whatever the response time exceeds 100 ms by.

How big is the gap in practice?

We measured our own site from six regions, in three runs, over the night of 13–14 August 2026 (UTC). lightscore.dev is one PHP box in Frankfurt with no CDNA network of edge servers that serve your content from near the visitor.in front of it, which makes it a good demonstration and a mediocre website. Each row is a single fetch. Full adds the four phases the report prints; request phase is the last of the four.

Tokyo waited 1,098 ms for the first byte, and a tool that counts only the request phase reports 306 ms for that same load. Both numbers are right. They are 3.6 times apart.

Frankfurt is the row that surprised me. The origin is in Frankfurt too, 2 ms of connect time from that worker, and it still took 495 ms to answer — longer than the fetch from Johannesburg. Same server, same page, about ninety minutes apart. One sample can't tell you why, and one sample is what the report has.

Each of those six results also carries Lighthouse's own figure for the same phase, measured on its own separate page load in the same job. Across the six regions the two disagree by between 3 ms and 578 ms. They time one phase on two different requests, so they have no reason to match.

Distance stretches the first byte, and it drags along the Lighthouse score that sits on top of it. We took that apart in do Lighthouse scores change when you test from a different region.

How do you reduce it?

1. Split the number first. DNS, connection, TLS and the request phase have four different fixes, and one figure hides which one you need.
2. Look at the hosting. web.dev puts this ahead of everything else: enough memory, a current backend stack, and room to configure it.
3. Put a CDN in front. The edge is nearer, so the connection phases shrink.
4. Cache the response. Even a short Cache-Control max-age pays off on a busy page, because only the first visitor in that window waits for the origin.
5. Delete redirects on the entry URL. Each hop costs a full round trip before the real page starts.
6. Stream the markup. The server sends the first chunk before the page is finished, instead of after.

A high TTFB isn't automatically a bug. web.dev says so directly: TTFB isn't a Core Web Vital, so meeting the threshold isn't mandatory when your paint metrics are already good.

What we report

Every Lightscore result carries the connection waterfall per region — DNS, connect, TLS, the request phase, download — next to the Lighthouse scores. That's one fetch per region, so read it as a sample and not as an average.

Our report labels the request phase TTFB, which is the narrow reading, the same one Lighthouse uses. Add DNS, connect and TLS to get the number a browser would give you. I'd rather print the split than one number that could mean either.

What we can't hand you is a field TTFB. Our workers are datacentre machines on fixed hardware, and Google's 800 ms threshold describes real Chrome users at the 75th percentile. Take that one from the Chrome UX Report. Ours is for comparing regions, builds and devices under conditions we hold still.