You optimized your server to respond in under 200ms. You confirmed it with synthetic monitoring, server logs, and CDN analytics. Then you opened the Largest Contentful Paint breakdown in Chrome DevTools or the Web Vitals extension, and the TTFB sub-part still consumed 800ms or more of your LCP budget. The number is not wrong — it is measuring something different from what your server logs measure. LCP’s TTFB attribution captures the entire duration from navigation start to the first byte of the HTML response as experienced by the browser, which includes DNS resolution, TCP connection, TLS negotiation, redirect chains, and service worker startup time — none of which appear in your server-side response time measurement. This article breaks down the exact mechanism behind LCP sub-part attribution and why server response time alone does not tell the full TTFB story.
How LCP Sub-Part Attribution Decomposes Total Load Time
LCP sub-part timing splits the total LCP duration into four sequential phases: TTFB, resource load delay, resource load duration, and element render delay. Google introduced this decomposition framework at Google I/O 2022 as a diagnostic technique for pages where image elements drive the LCP measurement, which accounts for approximately 73% of mobile pages according to HTTP Archive data from 2024.
The TTFB sub-part specifically measures from navigationStart (technically startTime on the PerformanceNavigationTiming entry) to responseStart as recorded by the Navigation Timing API in the browser. Every millisecond between the user initiating navigation and the first byte arriving at the browser’s network stack counts toward this sub-part, regardless of whether the origin server caused the delay. This distinction is critical because server-side instrumentation only captures a narrow slice of what the browser reports as TTFB.
As of February 2025, Google added LCP image subpart data to both the CrUX API and CrUX History API, exposing the 75th percentile of each sub-part in milliseconds. This means the TTFB attribution discrepancy between server logs and field data is now visible at scale through CrUX, not just in individual DevTools sessions. For text-based LCP elements (headings, paragraphs), only two sub-parts apply — TTFB and element render delay — because no external resource requires loading.
Google’s own optimization guidance suggests that if TTFB consumes more than 40% of total LCP time, it warrants dedicated investigation. The sub-part framework exists to prevent teams from optimizing the wrong phase, which is exactly what happens when server response time is conflated with browser-measured TTFB.
Network Latency Between Server Response and Browser Receipt
Server-side metrics like application response time capture only the duration from request receipt to response dispatch. The responseStart - requestStart calculation in the Navigation Timing API approximates this server processing window from the client side. But the LCP TTFB sub-part uses a broader formula: responseStart - startTime, which encompasses everything before the server even receives the request.
How Connection Reuse and Protocol Differences Inflate TTFB
The components that inflate browser-measured TTFB beyond server response time include DNS lookup (translating the domain to an IP address), TCP connection establishment, TLS handshake (negotiating encryption), and any redirect resolution that occurs before the final request reaches the origin. On mobile networks with high latency, these pre-server phases routinely add 300-600ms. A user on a 4G connection in a region distant from the nearest CDN edge server might experience 400ms of connection overhead alone, which the server never sees but the browser fully attributes to TTFB.
The web-vitals JavaScript library provides a TTFB attribution breakdown that isolates redirectTime, workerAndCacheTime, dnsTime, tcpTime, sslTime, and requestTime as separate values. This granularity is essential because a blanket “reduce TTFB” recommendation is meaningless without knowing which sub-component dominates. A site with 180ms server response time and 500ms total TTFB has a network-layer problem, not a server-side problem, and the optimization strategy for each is fundamentally different.
The introduction of 103 Early Hints adds further complexity. When a server sends a 103 response before the final 200 response, the responseStart timestamp captures the arrival of the 103 response — not the full HTML. Sites using Early Hints may see artificially low TTFB in the Navigation Timing API while the actual HTML delivery takes longer. The finalResponseHeadersStart property, where supported, provides the more accurate measurement of when the final response begins.
DNS Resolution, TLS Negotiation, and Redirect Chain Overhead
Redirect chains are the single most common hidden contributor to inflated TTFB attribution. Each 301 or 302 redirect adds a full round trip — DNS resolution, TCP connection, and TLS handshake may need to repeat for each hop if the redirect crosses domains. The Navigation Timing API counts all redirect time within the TTFB measurement window. A common pattern involves HTTP-to-HTTPS redirects chained with www-to-non-www redirects, adding 200-400ms of pure redirect overhead that lab tools often miss because they test the final URL directly.
Google’s web.dev documentation explicitly notes that field data should be the primary source for observing TTFB because it captures redirect latency that lab tools configured with final URLs systematically exclude. The waitingDuration sub-part of TTFB in the web-vitals library primarily consists of redirect time and browser queuing, and a high value almost always points to unnecessary redirects.
Service workers introduce another hidden layer. The workerStart value in the Navigation Timing API represents the time a service worker takes to boot from a terminated state before it can handle the navigation request. If the service worker has been evicted from memory (common on memory-constrained Android devices), this startup cost falls entirely within the TTFB window. The irony is that a well-configured service worker using a stale-while-revalidate caching strategy can deliver near-instant TTFB for repeat visitors — but only after the initial startup cost is paid. On first visit or after eviction, the worker boot time adds to TTFB without providing any caching benefit.
Server Processing Delays and CDN Edge Cache Miss Attribution
Diagnosing these contributors requires examining the full PerformanceNavigationTiming entry rather than relying on aggregate TTFB values. The sequence of redirectStart, redirectEnd, workerStart, fetchStart, domainLookupStart, connectStart, secureConnectionStart, requestStart, and responseStart reveals exactly where time accumulates.
The diagnostic workflow begins with the PerformanceNavigationTiming API, which exposes the granular timing breakdown needed to isolate each TTFB contributor. The calculation approach is sequential subtraction:
const nav = performance.getEntriesByType('navigation')[0];
const redirectTime = nav.redirectEnd - nav.redirectStart;
const dnsTime = nav.domainLookupEnd - nav.domainLookupStart;
const tcpTime = nav.connectEnd - nav.connectStart;
const tlsTime = nav.requestStart - nav.secureConnectionStart;
const serverTime = nav.responseStart - nav.requestStart;
const totalTTFB = nav.responseStart - nav.startTime;This decomposition reveals the gap. If totalTTFB is 800ms but serverTime is 150ms, the remaining 650ms distributes across redirect resolution, DNS, TCP/TLS, and any service worker overhead. Chrome DevTools’ Network panel waterfall view provides visual confirmation of these phases for individual page loads.
For field data at scale, the web-vitals library’s attribution build automatically captures these breakdowns per page view. Deploying this instrumentation through a RUM provider and segmenting by connection type (using the Network Information API’s effectiveType property) reveals whether the TTFB inflation concentrates on slow connections or affects all users equally. If the inflation is connection-dependent, the fix is network-layer optimization — CDN edge caching, connection reuse via HTTP/2 or HTTP/3, and DNS prefetching. If it affects all users, redirect elimination and service worker optimization take priority.
The critical diagnostic distinction is between one-time connection costs (DNS, TCP, TLS) that only affect cold navigations and per-navigation costs (redirects, service worker startup) that affect every page load. Repeat visitors with warm connections may show minimal TTFB inflation while new visitors on cold connections experience the full overhead.
Practical Limits of TTFB Optimization for LCP Improvement
Reducing TTFB beyond a certain floor yields diminishing LCP returns because the other three sub-parts may dominate the remaining budget. Google’s recommended proportion allocates roughly 40% of the LCP budget to TTFB, 40% to resource load duration, and no more than 20% combined for resource load delay and element render delay. A site with 150ms TTFB but a 2-second resource load delay for its hero image gains nothing from shaving 50ms off TTFB.
Data from the web.dev analysis of origins with poor LCP reveals that resource load delay — the time between TTFB and when the browser initiates the LCP image download — is frequently the largest overlooked bottleneck. The median site with poor LCP waits 1.3 seconds between TTFB and the start of the LCP image download. That single sub-part consumes more than half the 2.5-second LCP budget before the image even begins transferring.
This means that once TTFB is at or below 800ms (Google’s “good” threshold), optimization effort should shift to ensuring the LCP resource is discoverable by the browser’s preload scanner immediately during HTML parsing. A <link rel="preload"> hint for the LCP image or converting CSS background images to inline <img> elements with fetchpriority="high" typically produces larger LCP improvements than further TTFB reduction at that point.
The sub-part breakdown exists specifically to prevent misallocation of optimization effort. Teams that fixate on TTFB because it is the most visible and longest-established performance metric often miss that their actual LCP bottleneck sits in late resource discovery or render-blocking JavaScript. The correct approach is to measure all four sub-parts through field instrumentation, identify which phase dominates the 75th percentile LCP, and allocate engineering resources to that phase first.
Does reducing TTFB always improve LCP proportionally?
No. Once TTFB falls below approximately 800ms, further reductions produce diminishing LCP gains. Resource load delay and element render delay often dominate the remaining LCP budget. A site with fast TTFB but a late-discovered hero image benefits more from adding a preload hint than from shaving additional milliseconds off server response time. Measuring all four LCP sub-parts reveals which phase actually needs optimization.
Can service worker startup time inflate TTFB in field data without affecting lab results?
Yes. Service workers evicted from memory on resource-constrained devices must boot before handling navigation requests, and that startup cost falls within the TTFB measurement window. Lab tools typically test with warm service worker caches, so this overhead never appears in synthetic tests. Segmenting field TTFB data by new versus returning visitors and by device memory exposes service worker boot as a contributing factor.
How does HTTP/3 affect the TTFB sub-part breakdown compared to HTTP/2?
HTTP/3 eliminates TCP connection setup and TLS negotiation as separate sequential steps by using QUIC, which merges them into a single handshake. This compresses the connection-related TTFB sub-parts, particularly on high-latency mobile networks. The server processing time sub-part remains unchanged. Sites seeing TTFB inflation concentrated in connection overhead rather than server time gain the most from HTTP/3 adoption.
