TTFB measures the time from when the browser sends the page request to when it receives the first byte of the HTML response. It is almost entirely a server-side metric.
What it includes
TTFB accumulates several layers of latency:
- DNS lookup — resolving the domain to an IP address.
- TCP connection — establishing the network connection to the server.
- TLS handshake — negotiating encryption on HTTPS.
- Server processing — time your server spends generating the response.
Once the first byte arrives, the browser can begin parsing HTML. Until then, the user sees a blank screen.
How Witnes captures it
Witnes reads TTFB from the browser's PerformanceNavigationTiming API:
responseStart − requestStart. This is a browser-native measurement taken at
the network layer — it doesn't depend on JavaScript execution timing and is not affected by
client-side rendering.
What good looks like
Witnes displays TTFB as a raw number — it does not apply a Good / Needs Improvement / Poor label to TTFB directly. The table below shows Google's Web Vitals reference thresholds as a guide:
| Range | Assessment |
|---|---|
| < 800 ms | Good |
| 800 ms – 1 800 ms | Needs Improvement |
| > 1 800 ms | Poor |
A high TTFB will typically push LCP up, which does affect the Overall Health score.
When TTFB is slow
A high TTFB usually points to one of:
- Server-side rendering taking too long (database queries, external API calls).
- The server being geographically far from the user — consider a CDN or edge deployment.
- No caching on frequently-requested pages.
- DNS TTLs not configured — repeated lookups add latency.