What is Time to First Byte (TTFB)?

Time to First Byte (TTFB) is the time between the browser sending a request and receiving the first byte of the server response. TTFB measures how quickly a server reacts, which directly affects the load time of a page and its Core Web Vitals score for Largest Contentful Paint. A good TTFB value is usually 0.8 seconds or below.

TTFB is one of the first measurable numbers in the loading process of a web page. The value shows how long the server takes to respond to a request at all, before the browser can even start rendering. A high TTFB delays everything that follows and drags down the whole PageSpeed score. That is why TTFB is a standard figure in every technical load time analysis.

TTFB at a glance

What is a good TTFB value?

A good TTFB value is 0.8 seconds (800 milliseconds) or below. Google (web.dev) splits Time to First Byte into three bands: up to 0.8 seconds counts as good, between 0.8 and 1.8 seconds as needs improvement, and above 1.8 seconds as poor.

These thresholds are guide values, not a hard ranking criterion. TTFB is not an official Core Web Vitals metric itself but a diagnostic step before them: a high TTFB eats up the time budget that the Core Web Vitals need for fast rendering. Push the TTFB down and you create room for a better Largest Contentful Paint.

What does TTFB consist of?

TTFB adds up every phase between sending the request and receiving the first byte. The value consists of five phases:

1. Redirects: every 301 or 302 redirect costs an extra round trip to the server.
2. DNS lookup: the domain is resolved into an IP address.
3. TCP connection and TLS handshake: browser and server establish the connection and negotiate the encrypted HTTPS session.
4. Request: the browser sends the actual HTTP request.
5. Server processing: the server generates the response. This is often the largest share of the time, because database queries and assembling the page happen here.

The TTFB measurement ends only once the first byte of that response reaches the browser. Server processing is the decisive lever on most websites, because dynamic pages run through the database and the application logic at this point.

What affects Time to First Byte?

TTFB is determined mainly by the server, the connection path and the page logic. Four factors have the strongest effect:

• Hosting and server performance: overloaded shared hosting responds more slowly than a dedicated or well scaled setup. A weak CPU and little memory stretch the processing time.
• Server-side processing: expensive database queries, uncached calculations and heavy application logic drive the response time up. On WordPress, for example, every page is generated dynamically from PHP and the database whenever no caching kicks in.
• Geographic distance: the further a visitor is from the server, the longer the network round trips take. A server in Frankfurt serves German visitors faster than one in the United States.
• Redirects and connection setup: redirect chains and a slow TLS handshake each add a delay of their own.

In practice, missing caching is the most common cause of a high TTFB. Without a cache the server reassembles every request from scratch instead of serving a finished version.

How do you reduce TTFB?

You reduce TTFB by getting the server to deliver a finished response faster. Five measures work most reliably:

1. Set up caching: a page cache serves finished HTML pages instead of generating them for every request. It is the single most effective lever for dynamic pages.
2. Use a CDN: a content delivery network (CDN) serves content from a server location close to the visitor and shortens the network distance.
3. Choose better hosting: more CPU, more RAM and a server location in the target region noticeably cut processing and network time.
4. Optimize server logic and database: clean up slow database queries, run a current PHP version, switch on object caching.
5. Reduce redirects: remove every avoidable redirect chain so that no extra server round trip is needed.

Which measure pays off most becomes clear through structured measurement. That is exactly what a technical SEO audit delivers: it measures the TTFB, maps it to its causes and prioritizes the most effective levers.

TTFB vs. load time: what is the difference?

TTFB measures only the start, load time the whole process. TTFB ends at the moment the first byte of the server response arrives at the browser. Full load time also covers downloading all resources, rendering and displaying the page.

• TTFB: the response time of the server, before any content flows at all. A pure server and network value.
• Load time: the time until the page is displayed in a usable state, measured for instance through Largest Contentful Paint. It additionally depends on images, scripts and rendering.

In short: TTFB is the first building block of load time. A low TTFB does not guarantee a fast page, but a high TTFB makes a fast page impossible, because everything else waits on it.

Frequently asked questions about TTFB

Is TTFB a Google ranking factor?
TTFB is not a direct ranking factor and not an official Core Web Vitals metric. It does influence Largest Contentful Paint, which is part of the Core Web Vitals, and therefore has an indirect effect on rankings.

Which unit is TTFB measured in?
TTFB is measured in milliseconds and often stated in seconds as well. The guide value for a good result is 800 milliseconds, which is 0.8 seconds.

What do you measure TTFB with?
Tools such as PageSpeed Insights, the Chrome DevTools (network tab, the Waiting/TTFB column), WebPageTest or the JavaScript Navigation Timing API measure TTFB. PageSpeed Insights reports it as server response time.

Why is my TTFB so high?
The most common causes of a high TTFB are missing caching, weak hosting, slow database queries and a large geographic distance to the server. Caching and a CDN fix most cases.