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

What is Time to First Byte (TTFB)?

Time to First Byte (TTFB) is the time between the start of a navigation and the moment the first byte of the response arrives in the browser. It includes redirects, service worker startup, DNS lookup, the connection and TLS handshake, the request, and the server's own processing time. Nothing can render until it is over.

TTFB is not a Core Web Vital, but it sits in front of First Contentful Paint and Largest Contentful Paint, so a slow response leaves less of the LCP budget for everything else. See the web.dev TTFB guide for the reference definition.

What makes up TTFB

Server processing is usually the part you control most. Distance to the server (network latency) is the part a CDN controls.

TTFB thresholds

Google evaluates this at the 75th percentile of real page loads. web.dev calls 0.8 seconds a rough guide, not a strict rule. A server-rendered page with a higher TTFB can still have a good LCP, while a client-rendered app depends more on a fast response.

A worked example

With illustrative numbers, a shop's product page shows 120 ms for DNS, connection and TLS combined, and 40 ms for the response to travel back, but the server takes 900 ms to build the HTML because it runs 30 sequential database queries. TTFB lands at about 1.06 s, so LCP cannot be better than that. Caching the rendered HTML at the edge for a short time, or collapsing the queries into a few indexed ones, removes most of the 900 ms. The network part barely changes. This is why you break TTFB into phases before optimising.

How to measure TTFB

In the browser, the Navigation Timing API reports it directly. responseStart is measured from the start of the navigation, so it already includes redirects, DNS and the handshake:

new PerformanceObserver((list) => {
  const [nav] = list.getEntriesByType('navigation');
  console.log('TTFB:', nav.responseStart, 'ms');
}).observe({ type: 'navigation', buffered: true });

From the command line, curl reports each phase. time_starttransfer is the time from the start until the first byte was received:

curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.com

You can also run the LoadFocus website speed test or check real-user data with the Core Web Vitals checker. Lab tools show one load from one place. Field data from real user monitoring or the Chrome UX Report shows what your visitors actually get, redirects included.

How to reduce TTFB

• Serve cacheable pages from a CDN. A content delivery network answers from an edge server near the visitor, with correct Cache-Control headers. Personalised pages cannot be cached this way.
• Remove redirects. Fix links that go through http to https, a missing www or a trailing slash. Each one costs a round trip.
• Speed up the backend. Add database indexes, remove N+1 queries, cache expensive results and avoid blocking on slow third-party calls.
• Stream or pre-render. Send HTML in chunks while it is generated, or build static pages at deploy time when they do not need to be personalised.
• Use 103 Early Hints. It lets the browser start fetching critical resources while a slow backend finishes the response.
• Measure the backend with Server-Timing. The header exposes database, rendering and cache-miss time per request.

Common mistakes

• Measuring only the cached response. Caching and Early Hints can hide a slow origin. Test an uncached URL to see the real server time.
• Using responseStart - requestStart as "TTFB". That leaves out redirects, DNS and the handshake, so it understates what users wait for.
• Judging from a single lab run. TTFB varies with location and load. Look at the 75th percentile over many visits.
• Ignoring cold starts. A serverless function or an idle container can add a long delay to the first request after a quiet period.
• Assuming TTFB is fine under load. A page that responds in 300 ms to one visitor can take seconds when hundreds arrive together.

TTFB, load testing and monitoring

Because server processing is the variable part, TTFB is sensitive to traffic. LoadFocus load testing runs your site or API from 25+ cloud regions and shows response times as concurrent users rise, so you can see whether the backend slows down before it reaches production traffic. Page Speed Monitoring repeats Lighthouse audits on a schedule from 25 regions, so a TTFB regression after a deploy shows up as a trend. For a monitoring routine that includes Core Web Vitals, see how to monitor Core Web Vitals with alerts and reports.

FAQ: Time to First Byte

What is a good TTFB?

0.8 seconds or less at the 75th percentile is rated good, and more than 1.8 seconds is rated poor. Treat 0.8 s as a rough guide: what matters in the end is whether FCP and LCP are good for your visitors.

Is TTFB a Core Web Vital?

No. The Core Web Vitals are LCP, INP and CLS. TTFB is a diagnostic metric that explains part of a slow LCP or FCP.

How does a CDN improve TTFB?

It answers cacheable requests from an edge server close to the visitor, which shortens the connection setup and removes the trip to the origin. It does not help for responses that must be generated per user unless the CDN can cache them or run the logic at the edge.

Why is TTFB different in lab tools and field data?

A lab tool measures one load from one location on a fixed network. Field data covers real visitors, including their redirects, devices and distance from your servers, so the two rarely match.

What is the difference between TTFB and server response time?

Server response time covers only the backend work. TTFB also includes redirects, DNS, the connection, TLS and the network trip, so for visitors far from your server it can be much larger.