Time to First Byte (TTFB)
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.
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 will contribute to a lower TTFB.
What is a good TTFB score? #
Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP), it's recommended that your server responds to navigation requests quickly enough so that the 75th percentile of users experience an FCP within the "good" threshold. As a rough guide, most sites should strive to have Time To First Byte of 0.8 seconds or less.
How to measure TTFB #
TTFB can be measured in the lab or in the field in the following ways.
Field tools #
Lab tools #
- In the network panel of Chrome's DevTools
- WebPageTest
Measure TTFB in JavaScript #
You can measure the TTFB of navigation requests in the browser with the Navigation Timing API. The following example shows how to create a PerformanceObserver that listens for a navigation entry and logs it to the console:
new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');
console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
type: 'navigation',
buffered: true
});The web-vitals JavaScript library can also measure TTFB in the browser with less complexity:
import {onTTFB} from 'web-vitals';
// Measure and log TTFB as soon as it's available.
onTTFB(console.log);Measuring resource requests #
TTFB applies to all requests, 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 the Resource Timing API within a PerformanceObserver:
new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
for (const entry of entries) {
// 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 above 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 of 0, since the connection is already open, or a resource is instantaneously retrieved from a cache.
How to improve TTFB #
Improving TTFB is largely dependent on your hosting provider and backend application stack. High TTFB values could be due to one or more of the following problems:
- Hosting services with inadequate infrastructure to handle high traffic loads
- Web servers with insufficient memory that can lead to thrashing
- Unoptimized database tables
- Suboptimal database server configuration
Minimizing TTFB is often done by choosing a suitable hosting provider with infrastructure to ensure high uptime and responsiveness. This—in combination with a CDN—can help.
Other opportunities to improve high TTFB times and related perceptual delays include:
- Avoid multiple page redirects.
- Preconnect to required origins for cross-origin resources.
- Submit your origin to the HSTS preload list to eliminate HTTP-to-HTTPS redirect latency.
- Use HTTP/2 or HTTP/3.
- Consider predictive prefetching for fast page navigations for users who have not specified a preference for reduced data usage.
- Use server-side generation (SSG) for markup instead of SSR where possible and appropriate.