# Time to first byte

Time to first byte, TTFB, is the interval from the start of the request to the arrival of the first byte of the response. Good is under 0.8 seconds and poor is over 1.8 seconds, as web.dev publishes them. It is not a Core Web Vital, but every other timing inherits it.

Updated 2026-09-15 · Source: https://porteur.ai/glossary/time-to-first-byte

## What the number contains

- Any redirects, each with its own round trip.
- The DNS lookup, if the host is not already resolved.
- The TCP connection and the TLS handshake.
- The server’s own work: routing, database calls, rendering.
- The first byte travelling back to the browser.

> This is why a redirect chain shows up as a slow first byte: two extra hops are two extra round trips before the server even starts on the real page.

## The thresholds and where to read them

| TTFB | Reading |
| --- | --- |
| Under 0.8 s | Good |
| 0.8 s to 1.8 s | Needs improvement |
| Over 1.8 s | Poor |

PageSpeed Insights shows it in the field section when your site has enough traffic, and in the diagnostics of the lab run as the server response time. A browser’s network panel shows it per request under Waiting.

## What improves it

1. **Cache or pre-render the HTML** A page built at request time on every visit pays for that work every visit. Static generation or a cached response removes it.
2. **Put a CDN in front** Most of a slow first byte for a distant visitor is distance. A CDN answers from near them.
3. **Remove the redirects** Point the first URL straight at the final one. Each hop removed is a round trip saved.
4. **Turn on HTTP/2 or HTTP/3** Both remove connection overhead; they are set at the server or the CDN and cost nothing to the page.
5. **Make the server work less** The database call in the layout that runs on every page is the usual culprit on a small site.

## Questions

### What is a good time to first byte?

Under 0.8 seconds is good and over 1.8 seconds is poor, as web.dev publishes the thresholds. Between the two is worth improving when other work is done.

### Is TTFB a ranking factor?

Not directly. It is not a Core Web Vital. It is inherited by First Contentful Paint and Largest Contentful Paint, which do count, so a slow first byte costs you through them.

### Why is my TTFB slow only for some visitors?

Usually distance and cache state. A visitor near your server with a warm cache gets a fast response; one on another continent hitting a cold page waits for the round trips and the render.

### Does a CDN fix TTFB?

It fixes the distance part, which is often most of it. It cannot fix a server that takes a second to build the page, unless the CDN can cache that page.

### How do I measure TTFB?

The field section of PageSpeed Insights for real visitors, the network panel of a browser for one request, or a server response check that reports the first byte for a URL you paste.

## Read next

- [Time to first byte: the delay every other metric inherits](https://porteur.ai/guides/time-to-first-byte): TTFB sets the pace for every other speed metric. See what it includes, how to test it in field and lab, the causes on product sites, and the fixes.
- [Core Web Vitals](https://porteur.ai/glossary/core-web-vitals): Core Web Vitals are Google’s three field speed and responsiveness metrics. See their thresholds, lab versus field, how to read them, and what to fix.
- [Largest Contentful Paint (LCP)](https://porteur.ai/glossary/largest-contentful-paint): Largest Contentful Paint is when the biggest element appears. Aim under 2.5 s. See how to measure it, usual causes on small sites, and quick fixes.
- [Server response checker](https://porteur.ai/tools/server-response-checker): Paste a URL and time the server's answer: time to first byte, HTTP/2 or HTTP/3, brotli or gzip, Cache-Control, HSTS, the headers that decide when a page starts.
- [CDN](https://porteur.ai/glossary/cdn): A CDN serves your site’s files from servers near visitors. It cuts TTFB, speeds pages, reduces origin load and handles TLS, HTTP/2 and HTTP/3.
- [Redirect chain](https://porteur.ai/glossary/redirect-chain): A redirect chain is a URL that redirects to a URL that redirects again. What each hop costs, how many Google follows, and how to flatten one.
- [How to read PageSpeed Insights: field data first, then the score](https://porteur.ai/guides/how-to-read-pagespeed-insights): Start with field data, not the score. Learn what Google uses, why scores vary, and how to turn a PageSpeed Insights run into a clear order of fixes.
- [First Input Delay](https://porteur.ai/glossary/first-input-delay): First Input Delay measured the wait before the browser handled a first interaction. It was retired in March 2024 and replaced by Interaction to Next Paint.

The free check measures how your home page answers and paints on a phone, and names the first thing to fix, in about thirty seconds. Free check: https://porteur.ai/