What Is TTFB?

Time to First Byte measures how long passes between the browser requesting a page and receiving the first byte of the response. It is not load time: when that first byte arrives, nothing is visible on screen yet. It is the moment the server stops thinking and starts talking.

web.dev gives 800 milliseconds as the reference for a good value and 1,800 as the limit of the acceptable. Unlike the Core Web Vitals, TTFB is not a metric you are assessed on; it is an upstream diagnosis that explains much of what happens afterwards.

The most widespread misunderstanding is taking it for "the server's time". TTFB contains, in order: any redirects, service worker startup, the DNS lookup, the TCP connection, the TLS negotiation, sending the request, and finally the server's work. On many slow sites the backend is the fastest stage of them all.

That composition explains why two pages on the same server can produce very different values. One requested directly starts cold once; one reached through an old link with a 301 redirect repeats half the chain before it even begins.

Two close relatives regularly get confused with it. Server response time is only the last stage of TTFB; network latency is only one of the middle ones. TTFB covers both and everything else before the first byte, and that is exactly its use: it is the only measurement spanning the whole route.

For an e-commerce shop with a large catalog that distinction has budget consequences. Moving to more expensive hosting fixes the last stage; if the time went into resolving DNS at a slow provider or into an inherited chain of hops, the money buys nothing.

A redirect does not add "one more step". It adds the entire preceding chain again, often against a different domain, forcing DNS resolution and TLS negotiation from scratch.

The classic case is the old link pointing at http:// without www: the browser jumps to the HTTPS version, from there to the www one, and only then receives the page. Three complete chains for one visit, all of them running before the user sees a single pixel.

From that follows a rule for any linking work: always link to the final destination, in internal linking as in campaigns. A misplaced tracking parameter causing an extra hop multiplies the cost on every paid click.

Redirects also consume crawl budget: each hop is a request the crawler has to make to arrive at the same place. On a large site that competes with the pages you actually want it to look at.

Redirect chains grow by themselves and almost never by decision. They accumulate with every migration, every change of URL structure, every campaign that launched its own short address. Nobody deletes them because each one works; the cost appears on no screen and only shows up summed in TTFB.

Reviewing them is among the most rewarding tasks in an audit because the fix is permanent: once links point at the final destination, the problem does not return. And it helps speed, crawl budget and internal linking at once, three things that rarely improve from a single change.

The first step is separating the stages, because the measures differ for each. The browser's network panel breaks the time down into DNS wait, connection, TLS and response wait, and that tells you whether the problem sits before or inside the server.

If response wait dominates, the work is in the backend: unindexed database queries, templates regenerated on every visit, calls to external services inside the request cycle. Page caching often resolves the case entirely, because it turns a computation into a read.

If connection dominates, distance is the problem. A server in Frankfurt serves a visitor in Santiago with a physical delay no code optimisation removes; there a content delivery network helps, serving from a nearby node.

If there are redirects, remove them first, because they are the only stage you can delete outright rather than merely speed up. Then check in Search Console whether field data follows, bearing in mind it takes weeks to move.

One measure gets overlooked and costs little: checking that caching actually applies where people arrive. Many configurations automatically exclude any URL with parameters, and those are precisely the ones receiving campaign traffic, complete with the tags set through Google Tag Manager.

The result is a site that looks fast in tests and is slow for whoever arrives from an ad, usually the most expensive visitor. Measure with the complete URL, parameters included, rather than the clean version you type by hand.

TTFB is the first of the four sub-parts LCP breaks into. Everything spent here carries over in full: if the first byte lands after one second, 1.5 seconds remain to download and paint the main image if you want to stay in the good band.

A high TTFB is therefore the most frequent explanation for an LCP that will not come down however much the images are optimised. Changing the file format achieves nothing while the browser does not yet have the HTML that mentions the file.

With INP the relationship is indirect but real: a slow server often comes with plenty of JavaScript compensating in the client for what was not solved on the server, and that occupies the main thread exactly as the user starts interacting.

For a technical SEO audit that implies an order: look at TTFB before anything else. It is the only metric in this family whose improvement drags the others along automatically.

The same relationship explains why TTFB comes up in crawl budget discussions. Every page the crawler requests costs server time, and a high TTFB reduces how many pages it gets through in a session. On a site with thousands of URLs that decides what goes un-indexed for weeks.

There is also a second-order effect rarely mentioned: a slow server invites compensation in the browser. JavaScript gets added so the page "feels" fast, and that code ends up competing for the main thread exactly when the user wants to interact, which worsens INP. Server sluggishness is paid for twice.

• Taking TTFB for "the server's time" and switching hosts when the problem was a redirect chain.
• Measuring from the office and concluding it is fine: distance to the server changes the result more than almost any optimisation.
• Switching on caching without checking it actually applies to the pages receiving the traffic, which are usually the ones carrying parameters.
• Optimising images to bring down LCP without looking at TTFB first, which is the sub-part dragging it.
• Leaving old internal redirects in place because they "work": they work for the user and cost on every visit and every crawl.