Time to First Byte (TTFB)

What is Time to First Byte (TTFB)?

Time to First Byte (TTFB) measures how long a client waits from starting a request until the first byte of the response arrives. It is one of the oldest web performance metrics and still one of the most useful, because nothing can render before the first bytes of the HTML arrive. A slow TTFB pushes back every later milestone, including Largest Contentful Paint.

TTFB is a foundational, diagnostic metric rather than one of the Core Web Vitals. It tells you whether the delay is happening before the browser even gets content, which usually points to the network path or the server.

What TTFB includes

For a page navigation measured in the browser, TTFB is the sum of several phases:

1. Redirects, if the requested URL first answers with 301 or 302.
2. Service worker startup, if one is registered.
3. DNS lookup to resolve the hostname.
4. TCP connection and TLS handshake.
5. Request transfer and server processing: routing, application code, database queries, cache lookups and template rendering.
6. The first byte travelling back to the client.

In the Navigation Timing API, TTFB corresponds to responseStart relative to the start of the navigation. Server-side tools often report a narrower number, the time from receiving a request to sending the first byte. Both are useful, but they are not the same, so always state which one a dashboard shows. The gap between them is network latency and connection setup.

What is a good TTFB?

Google's web.dev guidance suggests that most sites should aim for a navigation TTFB of 0.8 seconds or less at the 75th percentile, and treats values above 1.8 seconds as poor. This is a rough guideline, not a hard rule: a server-rendered page that streams its HTML may have a higher TTFB and still load quickly, while a client-rendered app may have a low TTFB but render content late. TTFB is best judged together with LCP.

It also helps to look at TTFB by segment. Cached and uncached responses, logged-in and anonymous users, and different regions often have very different values. A healthy p75 for the whole site can hide a poor experience for users far from the origin or for pages that always bypass the CDN cache. Tracking TTFB over time is equally important: a gradual increase after releases is an early sign of growing backend work per request.

Example: measuring and breaking down TTFB

In the browser, the value can be read directly:

const [nav] = performance.getEntriesByType("navigation");
console.log("TTFB ms:", nav.responseStart - nav.startTime);
console.log("DNS ms:", nav.domainLookupEnd - nav.domainLookupStart);
console.log("Connect + TLS ms:", nav.connectEnd - nav.connectStart);

From the command line, curl shows the same split for a single request:

curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}\n" https://example.com/

On the server, the Server-Timing response header can report how long individual steps took, for example Server-Timing: db;dur=120, render;dur=45, which browsers and RUM tools can display next to TTFB. The numbers in such a breakdown are illustrative; what matters is which phase dominates.

How to reduce TTFB

• Cache close to users with a CDN, including HTML where possible.
• Remove unnecessary redirects, for example from http to https and then to a www host.
• Speed up the backend: fix slow database queries, N+1 patterns and blocking calls to downstream services.
• Keep connections warm with HTTP/2 or HTTP/3, connection reuse and TLS session resumption.
• Avoid cold starts in serverless or autoscaled environments for latency-critical paths.
• Stream the response so the first bytes can be sent before the whole page is ready.

Common mistakes

• Comparing server-side processing time with browser TTFB and wondering why they differ.
• Measuring only from one location close to the data centre.
• Optimising TTFB at the cost of LCP, for example by sending an empty shell that renders content much later.
• Looking at averages instead of p75 and p95, which hides slow regions and cache misses.

How Obseria helps

Obseria's real user monitoring records TTFB and its phases from real sessions, while synthetic checks measure it from defined locations. Because browser spans are linked to backend traces via distributed tracing, a slow TTFB can be followed to the exact service, query or downstream call that consumed the time.