Time to First Byte (TTFB)

Jeremy Wagner

Barry Pollard

Browser Support

What is TTFB?

TTFB is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive.

A visualization of network request timings. The timings from left to right are Redirect, Service Worker Init, Service Worker Fetch event, HTTP Cache, DNS, TCP, Request, Early Hints (103), Response (which overlaps with Prompt for Unload), Processing, and Load. The associated timings are redirectStart and redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart, and loadEventEnd. — A diagram of network request phases and their associated timings. TTFB measures the elapsed time between`startTime`and`responseStart`.

TTFB is the sum of the following request phases:

Redirect time
Service worker startup time (if applicable)
DNS lookup
Connection and TLS negotiation
Request, up until the point at which the first byte of the response has arrived

Reducing latency in connection setup time and on the backend can lower your TTFB.

Other definitions of TTFB

The previous definition is the conventional definition but with the introduction ofEarly Hintswhat is considered the "first byte" is up for debate. ThefirstInterimResponseStartis an new additional timing entry toresponseStartto differentiate between these but this is only supported in Chrome and Chromium-based browsers. Therefore some browsers and tools (including CrUX) measure until the first bytes are received including Early Hints.

Early Hints is just a newer example of responding early. Some servers allow flushing of the document response to happen before the main body is available—either with just the HTTP headers, or with the<head>element, both of which could be considered similar in effect to Early Hints and so also cloud the definition of what TTFB measures.

As a measure of when the "first bytes" of actionable data for the document are received by the browser, all these definitions could be considered valid, There is real value in sending back data early if the full response is going to take some more time. What is most important is to understand what the measure the tool you are using measures and how that is affected by the platform being measured. This does make it difficult to compare TTFB across different platforms or technologies depending on what features they use, and how that impacts the TTFB measurement being used.

TTFB is also often considered as an indicator of server or host response time. However, it will be affected by factors outside of that direct control such as redirect time, whether it is served from a cache hit by a CDN or has to make a potentially longer journey back to an origin server. This is particularly apparent in field data—lab testing typically is less affected by these factors since the end URL is usually tested and often repeatedly negating caching changes. Lighthouse reportsserver response timerather than TTFB to make this clearer but other lab tools may not.

What is a good TTFB score?

Because TTFB precedesuser-centric metricssuch asFirst Contentful Paint (FCP)andLargest Contentful Paint (LCP),it's recommended that your server responds to navigation requests quickly enough so that the75th percentileof users experience anFCP within the "good" threshold.As a rough guide, most sites should strive to have a TTFB of0.8 secondsor less.

Good TTFB values are 0.8 seconds or less, poor values are greater than 1.8 seconds, and anything in between needs improvement — Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.

Key point:Because TTFB isn't aCore Web Vitalsmetric, it's not absolutely necessary that sites meet the "good" TTFB threshold, provided that it doesn't impede their ability to score well on the metrics that matter.

Websites vary in how they deliver content. A low TTFB is crucial for getting markup out to the client as soon as possible. However, if a website delivers the initial markup quickly, but that markup then requires JavaScript to populate it with meaningful content—as is the the case with Single Page Applications (SPAs)—then achieving the lowest possible TTFB is especially important so that the client-rendering of markup can occur sooner.

Conversely, a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience. This is why the TTFB thresholds are a "rough guide", and will need to be weighed against how your site delivers its core content.

How to measure TTFB

TTFB can be measured inthe labor inthe fieldin the following ways.

Field tools

Lab tools

In thenetwork panelof Chrome's DevTools
WebPageTest

Measure TTFB in JavaScript

You can measure the TTFB ofnavigation requestsin the browser with theNavigation Timing API.The following example shows how to create aPerformanceObserverthat listens for anavigationentry and logs it to the console:

newPerformanceObserver((entryList)=>{
const[pageNav]=entryList.getEntriesByType('navigation');

console.log(`TTFB:${pageNav.responseStart}`);
}).observe({
type:'navigation',
buffered:true
});

Theweb-vitalsJavaScript librarycan also measure TTFB in the browser more succinctly:

import{onTTFB}from'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

Measure resource requests

TTFB applies toallrequests, not just navigation requests. In particular, resources hosted on cross-origin servers can introduce latency due to the need to set up connections to those servers. To measure TTFB for resources in the field, use theResource Timing APIwithin aPerformanceObserver:

newPerformanceObserver((entryList)=>{
constentries=entryList.getEntries();

for(constentryofentries){
// Some resources may have a responseStart value of 0, due
// to the resource being cached, or a cross-origin resource
// being served without a Timing-Allow-Origin header set.
if(entry.responseStart>0){
console.log(`TTFB:${entry.responseStart}`,entry.name);
}
}
}).observe({
type:'resource',
buffered:true
});

The previous code snippet is similar to the one used to measure the TTFB for a navigation request, except instead of querying for'navigation'entries, you query for'resource'entries instead. It also accounts for the fact that some resources loaded from the primary origin may return a value of0,since the connection is already open, or a resource is instantaneously retrieved from a cache.

How to improve TTFB

For guidance on improving your site's TTFB, see our in-depth guide tooptimizing TTFB.