# What is TTFB (Time to First Byte)?

> Time to First Byte (TTFB) is the time between a browser requesting a page and receiving the first byte of the response from the server.

URL: https://yes-seo.com/glossary/ttfb

**Time to First Byte (TTFB)** is how long a browser waits between asking for a page and receiving the first byte of the answer. Nothing can render before that byte arrives, so TTFB sets the floor for every other loading metric.

## What it includes

TTFB isn’t just “server thinking time”. Measured from the start of navigation, it covers:

- any redirects before the final URL;

- the DNS lookup, TCP connection and TLS handshake;

- the request reaching the server, the server building the response, and the first byte traveling back.

On a slow mobile connection, two redirect hops can cost more than the server itself.

## What’s a good TTFB?

web.dev suggests **0.8 seconds or less** as a rough guide for good and more than 1.8 seconds as poor ([web.dev: TTFB](https://web.dev/articles/ttfb)). TTFB isn’t a Core Web Vital, but it is the first part of [LCP](https://yes-seo.com/glossary/lcp): a 1.5-second TTFB leaves only a second for everything else if you want to stay within the 2.5-second LCP target.

Fast responses also help crawling. Google’s crawl budget documentation explains that when a site responds quickly for a while, Googlebot raises the number of requests it is willing to make.

## Measure it yourself

```
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\n" https://example.com/
```

Run it a few times. The first request may hit a cold cache; consistent results above a second point to the backend. If you build the app, the `Server-Timing` response header is an easy way to report where your own time goes — database, templates, cache hits — straight into browser developer tools.

## How to reduce it

- **Cache full pages.** A page cache or CDN edge cache turns a slow dynamic render into a quick file read.

- **Serve from close to users** with a CDN, especially for international audiences.

- **Remove redirect hops** and link straight to final URLs.

- **Fix slow database queries** and heavy plugins on pages that can’t be cached, such as search or cart.

- **Use HTTP/2 or HTTP/3**, and keep TLS session resumption enabled.

- **Send [103 Early Hints](https://yes-seo.com/http-status-codes/103)** so the browser can fetch CSS and fonts while the server is still working on the HTML.

## Common mistakes

- Testing from a single location next to your server and calling the site fast.

- Comparing a cached CDN hit with an uncached request to the origin.

- Obsessing over a few milliseconds of TTFB while the page then ships megabytes of JavaScript. It’s one part of [page speed](https://yes-seo.com/glossary/page-speed), not all of it.

- Forgetting logged-in users, who often bypass the page cache entirely.

## Test your server

The [page speed test](https://yes-seo.com/page-speed-test) reports server response time (TTFB) from our server, download time, HTML size and compression, and HTTP version, alongside Core Web Vitals from PageSpeed Insights when available.

## Frequently asked questions

### Is TTFB a ranking factor?

Not directly, and it isn’t a Core Web Vital. It matters because it delays LCP, which is part of page experience, and because faster responses let search engines crawl your site more efficiently.

### Why is TTFB slower on the first visit?

The first request has to resolve DNS, open a connection and complete the TLS handshake, and it may hit a cold server or CDN cache. Repeat requests can reuse connections and cached responses.

### What is the difference between TTFB and server response time?

Server response time is only the time the server spends building the response. TTFB also includes redirects, DNS, connection setup and network travel, so it is always the larger number.