# TTFB: What Time To First Byte Is and Why It Matters for Site Performance
Table of Contents
When you open a web page, there’s a moment of waiting before anything shows up: the loading indicator spins, the screen stays blank, and only then do text and images start to appear. A large part of that initial wait has a precise name: TTFB, or Time To First Byte. Understanding what it is helps you reason about a site’s performance without relying on vague impressions.
What TTFB is, in plain terms
TTFB measures the time between the moment the browser starts requesting a page and the moment it receives the first byte of the response from the server. In practice, it’s how long the server takes to start replying, not to finish.
A useful comparison: it’s like ordering at a restaurant. TTFB isn’t the time to finish your meal, nor the time to have the full dish in front of you. It’s the time between placing the order and the waiter coming back with the first course. If that first signal arrives late, everything else slips accordingly.
It’s worth clarifying one point right away: TTFB isn’t a single thing, but the sum of several steps. According to web.dev’s documentation, it includes the time for any redirects (bouncing from one address to another), the startup of a service worker if present, DNS resolution (translating the site’s name into the server’s numeric address), connection and TLS negotiation (the encrypted “handshake” that protects the data) and finally the processing of the request up to the first byte returned.
Why it matters to the people using the site
The first byte isn’t visible content yet: it’s just the signal that the response has begun. But until it arrives, the browser can’t do anything. It can’t read the HTML, download images or stylesheets, or draw anything on screen. A high TTFB pushes everything that follows further out.
For the user, this turns into a concrete feeling: the site seems “slow to start.” Even if the rest is well optimized, a server that takes too long to respond leaves the screen empty for longer, and the page feels like it isn’t working. On this point the guidelines offer a practical reference: a TTFB is considered good at 0.8 seconds or less and poor above 1.8 seconds. It’s not an absolute cutoff, but a useful order of magnitude to judge whether there’s room to improve.
TTFB, SEO and Core Web Vitals
This needs some context. Google uses a set of metrics called Core Web Vitals to measure the quality of a page’s loading experience, and these metrics are a factor that influences ranking in search results. There are three: LCP (Largest Contentful Paint, how long before the main content appears, good under 2.5 seconds), INP (Interaction to Next Paint, how responsive the page is to clicks, good under 200 milliseconds) and CLS (Cumulative Layout Shift, how much elements “jump” as the page loads, good under 0.1). Note that in 2024 INP replaced the older FID metric.
TTFB, on its own, isn’t one of the Core Web Vitals. But it precedes all of them. It’s the first building block that LCP in particular is built on: web.dev’s documentation describes it as the first part of LCP and estimates it can account for roughly 40% of it. The principle is simple: nothing can happen on the page until the server delivers that first byte, so anything that lowers TTFB tends to improve the other loading metrics too. Reducing TTFB doesn’t guarantee a good score by itself, but a high TTFB makes one much harder to reach.
What TTFB depends on
TTFB doesn’t come from a single factor, which is why it’s sometimes hard to diagnose. In general several layers come into play.
- The network and geographic distance. Every request physically travels between the user and the server. The farther apart they are, the more time is spent just moving the data, on top of the initial DNS lookup and TLS handshake.
- The server and hosting. An overloaded, undersized, or outdated server responds more slowly. Hosting quality is often the first thing to evaluate.
- The application. The code that generates the page can do heavy work on every request: computations, calls to external services, unoptimized processing. All of it piles up before the first byte.
- The database. If generating the page requires slow or too many queries, the server waits on the database before it can respond.
- Caching (or the lack of it). If every request is recomputed from scratch, you pay the full cost every time. Caching exists precisely to avoid that.
A high TTFB, then, is a symptom: the value has to be broken down to understand where the time is lost.
The general levers to improve it
There’s no single fix that works for everyone, and it’s always worth measuring before and after. That said, the common approaches are just a few, and they act on the layers described above.
- Caching. This is often the lever with the best effort-to-result ratio. The idea is to serve a ready-made result instead of recomputing it. It can happen at several levels: a page cache that keeps the already-generated HTML, a cache of data or queries and
Cache-Controlheaders, which tell browsers and intermediaries when to reuse a response. With effective caching, only the first request pays the full cost back to the origin server. - CDN (Content Delivery Network). A CDN is a network of geographically distributed servers that bring content closer to the user. It serves the response from a nearby node instead of the distant origin server, cutting the data’s travel time; CDNs also generally offer fast DNS, modern protocols like HTTP/2 and HTTP/3, and optimized TLS handling.
- Backend optimization. This covers everything that makes generating the response faster: more efficient database queries, less work done on each request, updated infrastructure. It’s the least “magical” and most hands-on part, but often the most decisive when the bottleneck is the application, as frequently happens with an online store grown over the years.
- Reducing redirects. Every bounce from one address to another adds a full network round trip before the server even starts replying. Removing needless redirects, where they’re under your control, helps.
In short
TTFB is the time before the first byte of the response: a small but foundational value, because the rest of the load starts from there. It isn’t an official Core Web Vitals metric, but it shapes them, which is why it affects both perceived experience and, indirectly, SEO. It depends on network, server, application, database and caching, and it’s addressed mainly through caching, CDNs and backend optimization. The practical rule stays the same: measure, find where the time is lost, and act on the right layer instead of changing everything at random.
