The “TTFB” reported in an LCP breakdown is not the origin server’s processing time; it’s the time from navigation start to the first byte of the document response, as defined by the Navigation Timing API, and that window includes every network-layer step before the origin server ever gets to run its application code. Redirect chains, DNS resolution, TCP connection setup, and TLS negotiation all happen before the server’s actual request-handling logic begins, and all of that time counts toward TTFB in the LCP breakdown. A backend that processes and returns a response in under 200ms can still show a TTFB of 600ms, 800ms, or more in Chrome’s LCP breakdown if there’s a redirect hop, a slow DNS lookup, or connection negotiation overhead sitting in front of that fast backend. Conflating “my server responds quickly” with “TTFB is low” is exactly the misconception this metric definition trips people into.
Mechanism
The Navigation Timing API measures TTFB as the elapsed time between startTime (the origin time for the navigation, effectively when the browser begins the process of loading the document) and responseStart (when the first byte of the actual response body begins arriving). Per web.dev’s own documentation on TTFB, this interval necessarily includes redirect time if any redirects occur, DNS lookup time, connection and TLS negotiation time, and only then the time the server actually spends generating the response, plus the network transit time for that first byte to arrive. All of those sub-steps are bundled into the single number reported as TTFB, both in the standalone TTFB metric and in the TTFB portion of an LCP timing breakdown.
Redirects are a particularly common and underappreciated contributor. Every redirect (an HTTP-to-HTTPS redirect, a non-www-to-www redirect, a trailing-slash normalization redirect, a marketing-URL-to-final-destination redirect) means the browser has to complete an entire round trip to receive the redirect response, then start the whole connection process over again for the new URL, including fresh DNS resolution and connection negotiation if the redirect target is a different origin. Two or three redirect hops stacked in sequence, each adding real round-trip time, easily add several hundred milliseconds before the origin server that ultimately serves the actual page is ever contacted, and every millisecond of that is counted as TTFB, not as some separate “redirect time” bucket that would let a fast backend look good in isolation.
DNS and connection setup compound this further. A DNS lookup that hasn’t been cached by the resolver the user’s device is using, connection negotiation to an origin that hasn’t been warmed up (no existing TCP connection, no session resumption for TLS), or a CDN/edge layer that has to negotiate its own connection to an origin before it can respond to the client, all add fixed network-latency costs that have nothing to do with server-side application processing time. This is precisely why field data (real users, varied networks, varied geographic distance, varied connection quality) so often shows TTFB figures that look disproportionate compared to a developer’s own lab measurement of “how long does my server take to build this response,” which is usually tested from a fast connection close to the server, skipping most of what real users experience upstream of the origin.
A hypothetical illustration
Hypothetically, imagine a marketing team at a subscription-box company confirms their application server generates a response in roughly 150ms and concludes TTFB can’t be the reason PageSpeed Insights is flagging LCP problems on mobile. A waterfall breakdown of the actual navigation might tell a different story: the marketing URL people click from an email redirects to a non-www canonical, which itself redirects to a locale-specific subdomain, two hops before the origin server is ever contacted, plus a cold DNS lookup on a mobile network with no cached resolution. Those steps alone could plausibly add several hundred milliseconds before the fast 150ms backend even starts working, which is enough on its own to push the page’s field-data TTFB into a “poor” categorization despite the backend being fully innocent.
Practical implication
Diagnosing a high TTFB contribution to LCP requires decomposing the navigation timeline rather than trusting a single aggregate number. Use the Navigation Timing API’s individual timestamps (or a waterfall view in Chrome DevTools’ Network panel, or a synthetic testing tool that exposes the breakdown) to see how much of the total is redirect time, how much is DNS, how much is connection/TLS negotiation, and only what’s left is genuine server processing and initial network transit. A page redirecting through two hops before reaching its final URL should have those redirects eliminated or collapsed to a single hop, since removing that entirely can improve TTFB more than any backend optimization would. A slow DNS resolution can often be addressed through DNS provider choice or resource hints like dns-prefetch for cross-origin resources, though the document’s own DNS lookup happens before any hint the document itself could provide. Connection negotiation overhead is reduced through techniques like connection reuse, HTTP/2 or HTTP/3 adoption, and serving from a CDN or edge location physically closer to the requesting user, which shortens the round-trip time each of these negotiation steps requires.
The core practical takeaway is to stop treating “server response time under 200ms” as evidence that TTFB is not a problem worth investigating. They are different measurements of different spans, and a fast backend sitting behind a slow network path (unnecessary redirects, cold DNS, distant or poorly negotiated connections) will still show a TTFB contribution to LCP that looks bad in PageSpeed Insights or CrUX field data, because that’s an accurate reflection of what the user’s browser actually experienced before the first byte arrived, regardless of how fast the application code itself ran once it started.
