What is TTFB? How to lower Time to First Byte

What TTFB measures

TTFB is the time between the start of a request and the moment the first byte of the response starts to arrive. For a web page, the request is the one for the HTML document, and it comes before everything else. The browser cannot start to read the page, find the images or run the scripts until it has something to read.

TTFB is not just the server thinking. It is the sum of these steps:

1. Redirects. Each redirect, such as http to https or a bare domain to www, is a full extra round trip.
2. Service worker startup, on sites that have one.
3. DNS lookup. Finding the server's address. See DNS speed.
4. Connection and TLS. Opening a connection and securing it. See connection setup and HTTPS and TLS speed.
5. The request itself. The server receives it, builds the page and starts to answer.

Steps 3 to 5 depend on distance: a visitor far from your server waits longer than one next to it.

What counts as a good TTFB

These marks are for real visits at the 75th percentile. TTFB is not one of the three Core Web Vitals, so a page is not failing Google's test because of it alone. It matters because it is the start of the clock for FCP and LCP: a page cannot show its main content sooner than the server starts sending it. Treat the marks as a rough guide. A server-rendered page can have a higher TTFB and still paint sooner than a page that answers fast with an empty shell and builds its content with JavaScript.

What the Lighthouse report says about it

Lighthouse does not give TTFB its own score. In version 13.5 it checks the page request in an insight called Document request latency, which fails when any of three things is true:

• the request went through one or more redirects;
• the server took longer than 600 milliseconds to start responding to the request;
• the HTML was sent without text compression.

The 600 milliseconds is the server's own response time, measured from the request being sent, so it is smaller than the full TTFB, which also includes the connection steps above.

What makes it slow

• Hosting that is the limit. An overloaded or underpowered server, or a shared server where other sites use up the resources.
• No page cache. A dynamic site such as WordPress runs code and database queries to build every page unless a cache keeps a finished copy.
• Slow work during the request. Plugins, database queries, or calls to outside services that have to finish before the server can answer.
• No CDN, so every visitor connects to one distant server.
• Redirect chains between the link a visitor clicks and the final address.
• Traffic spikes that the server cannot handle.

Find where the time goes

You cannot fix what you cannot see. Three ways to split TTFB into parts.

Chrome DevTools. In the Network panel, select the page request and open the Timing tab. "Waiting for server response" is the server's share.

The command line. One command shows each step:

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

The `Server-Timing` header. Your own code can say how long each part of building the page took, and DevTools shows it in the same Timing tab:

Server-Timing: db;desc="Database";dur=121.3, render;desc="Page render";dur=212.2

When the "waiting" time is long, this header shows whether the database, the template or an outside call is to blame.

How to lower it

Cache the finished page. A full-page cache lets the server send a saved copy instead of rebuilding the page for every visit. On WordPress, use a caching plugin or the cache your host provides. On other platforms, cache at the server or the CDN. This is usually the largest single gain on a dynamic site.

Serve pages from a CDN. A CDN keeps copies of your files on servers close to visitors. Most cache images, scripts and stylesheets; some can also cache the HTML page, so the answer comes from nearby. The page must be allowed to be cached, with correct Cache-Control headers, and personalized pages need care. See what a CDN is and whether you need one.

Remove redirects. Link to the final address: https, the version of the domain you use, and the trailing slash if your site uses one. A redirect inside your own site is cheaper than one that crosses to another domain, but both cost a round trip.

Choose better hosting. If caching and a CDN do not bring the time down, the server itself is the limit. Look for resources that are not shared with strangers, a current PHP version where it applies, an object cache such as Redis for database-heavy sites, and servers in the region where most of your visitors are.

Make the page cheaper to build. Remove plugins you do not use, fix slow database queries, and avoid slow calls to outside services while the page is being built. The guide on reducing server response time goes through the causes one by one.

Send the page in pieces. A server that can stream the HTML starts sending the top of the page while it still builds the rest, so the browser can begin work earlier.

Use `103 Early Hints`. The server can send a first, quick response that names the files the page will need, so the browser starts fetching them while the server is still preparing the page. It needs support on your server or CDN.

Check your own page

Run the free audit and look at the server response time and at whether the page was redirected. If the audit shows a long wait for the first byte, test the page again from a different place and at a different time of day. A wait that is long everywhere points at the server or the missing cache; a wait that is long only from far away points at the lack of a CDN.

Sources

• Time to First Byte (TTFB) on web.dev: the definition, the phases and the marks.
• Optimize Time to First Byte on web.dev: hosting, CDN, caching, redirects, streaming, Server-Timing and 103 Early Hints.
• Server-Timing on MDN.