What Is TTFB?
TTFB (time to first byte) is a timing metric that captures everything between a click and the moment your server starts answering: redirects, DNS, connection setup, and server processing.
TTFB (time to first byte) is a timing metric that captures everything between a click and the moment your server starts answering: redirects, DNS, connection setup, and server processing. It is not a Core Web Vital, and it says nothing about how fast a page looks. When the timer stops, the browser has painted nothing at all.
Why a slow first byte hurts
TTFB is a floor. Every millisecond spent before the response begins is a millisecond that no amount of front-end work can recover, because the browser has nothing to work with yet. Compress every image, inline your critical CSS, defer every script: the timer still started at whatever your server took to answer.
There is a second effect that has nothing to do with users. Google adjusts how hard it crawls based on how your server copes, easing off when responses slow down or errors appear. A server that struggles under load gets crawled more gently, which quietly slows discovery across a large site. If you are deciding where to spend a performance budget, look at which templates carry your traffic first, because response time on a template serving thousands of sessions is worth more than a millisecond anywhere else.
How TTFB is measured
The number is a sum, not a single event. Five things happen in order, and any one of them can dominate the total while the other four look healthy.
- Redirects. Each hop is a complete round trip that finishes before the real request starts. A chain from HTTP to HTTPS to www to a trailing slash spends three of them before anything useful happens.
- DNS lookup. The browser resolves your hostname to an address, unless it already holds a cached answer.
- Connection and TLS negotiation. The client opens a connection and negotiates encryption. Physical distance between visitor and server sets a hard limit here that no code change can beat.
- Server processing. Your application runs. Database queries, template rendering, and calls to third-party APIs all land in this window, and this is where most bad TTFB lives.
- First byte sent. The response starts arriving and the measurement stops. Everything the visitor can actually see comes after this point.
Measure it in the field rather than in a lab. A test run from a data centre next to your origin will report a number no real visitor experiences, and TTFB varies with distance, device, and network more than most of the metrics behind page speed. Google publishes 0.8 seconds as the good threshold for TTFB, assessed at the 75th percentile of real visits.
| Where the time goes | What usually removes it |
|---|---|
| Redirect chains on entry URLs | Link internally to the final URL and collapse the chain to one hop |
| Distance from server to visitor | Edge caching, or an origin nearer your actual audience |
| Uncached application responses | Full-page caching for anything not personalised |
| Slow database queries in the template | Indexes, query limits, and removing per-request lookups |
| Blocking third-party API calls | Move them client-side or cache the response |
The blunt version
TTFB is not a Core Web Vital and it is not a ranking factor. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. TTFB sits outside that set as a diagnostic metric, and no ranking system reads it.
It still matters, for one reason: it caps LCP. Largest Contentful Paint measures when the biggest visible element finishes rendering, and that clock starts at the same moment TTFB does. Your LCP can never be faster than your TTFB. The arithmetic decides the rest. The good threshold for LCP is 2.5 seconds. If your TTFB is 1.4 seconds, you have 1.1 seconds left for connection setup, CSS, fonts, and fetching and painting the hero image. That is not enough, and no image compression will create the missing time.
Run the rule in the other direction too. If your field TTFB is already 300 milliseconds and your LCP is 4 seconds, the server is not your problem and a hosting upgrade will buy you nothing. Someone will still sell you one, because server work is easy to scope and easy to invoice, while an oversized hero image is a conversation with a designer. Spend the money where the arithmetic points, and read what speed really does to rankings before signing anything.
Example
Say a retailer on shared hosting sees a field TTFB of 1.6 seconds on mobile and an LCP of 4.2 seconds. Category pages are generated from scratch on every request, including a stock lookup against a third-party API. Caching the rendered category pages at the edge, and letting the stock check run client-side after load, brings TTFB down to roughly 0.3 seconds. LCP improves to about 2.9 seconds, which is better and still not good. The remaining time is a hero image served at desktop dimensions to phones. The server fix was necessary and insufficient, which is the usual shape of this work.
FAQ
Is TTFB a Google ranking factor?
No. The Core Web Vitals used in Google’s page experience signals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. TTFB is a diagnostic metric that helps explain a poor LCP score. It influences rankings only through that relationship, never on its own.
What counts as a good TTFB?
Google publishes 0.8 seconds or less as good, measured at the 75th percentile of real user visits. Above roughly that mark, the server is eating a share of your LCP budget you cannot get back. Below it, further server tuning rarely changes what a visitor perceives.
Will a CDN fix my TTFB?
Only for responses it can cache. A hit at the edge is fast because it skips your origin entirely. A miss still travels the full distance and adds a hop. Personalised pages, logged-in views, and checkout flows usually miss, so measure those separately before assuming the problem is solved.
Related terms
- Faceted Navigation — the URL pattern that hands your server thousands of uncacheable requests to answer.
- Information Gain — the content-side test a fast page still has to pass.
- Page Speed — the wider set of measurements TTFB feeds into rather than replaces.
Fix TTFB because it caps your LCP, not because someone told you Google measures it. Google does not. Get the field number first, then decide whether the server or the render path is actually costing you the seconds.