Measuring Streaming Impact: FCP, TTI, and LCP

FCP measures the time from navigation start to when the first piece of content (text, image, or background) is painted to the screen. Streaming improves FCP by sending the HTML shell immediately — the browser can paint the layout, navigation, and any above-fold text as soon as the first chunks arrive.

With synchronous SSR (renderToString), the browser receives no HTML until the entire render is complete. With streaming, the browser receives the HTML shell within milliseconds of the request — the layout and static content appear almost immediately, dramatically reducing FCP.

LCP measures when the largest visible element in the viewport is painted — typically a hero image or a large heading. Streaming improves LCP if the LCP element is part of the shell (not inside a Suspense boundary), since the shell streams before any data-dependent sections.

A key optimization is designing your page so the LCP element — the hero section, the main heading, the featured image — lives outside any Suspense boundary. If the LCP element is inside a Suspense boundary awaiting data, streaming cannot help LCP until that data resolves.

TTI measures when the page reliably responds to user input — no Long Tasks blocking the main thread. Streaming combined with selective hydration reduces TTI by spreading the hydration work over time rather than executing one large synchronous hydration task after all JavaScript downloads.

Time to First Byte (TTFB) is determined by network latency and server processing time before the first byte is sent. Streaming doesn't change TTFB — that's where edge rendering helps. For streaming to improve FCP, you first need a low TTFB; otherwise you're just streaming from a slow origin.

WebPageTest's filmstrip view shows a sequence of screenshots taken every 100ms during page load. A streaming page shows the layout appearing early, then sections filling in progressively. A non-streaming page shows a blank screen followed by a sudden fully-rendered page — a clear visual difference.

A meaningful benchmark compares the same page rendered two ways: with Next.js RSC streaming enabled vs traditional synchronous SSR. Use WebPageTest with a fixed network condition (e.g., Fast 3G, 4x CPU slowdown) and compare FCP, LCP, and TTI metrics across 3 test runs for statistical confidence.

Chrome DevTools Network tab has a "Throttling" dropdown with presets like Fast 3G and Slow 4G. Fast 3G (1.6 Mbps, 150ms RTT) exaggerates the difference between streaming and non-streaming because it amplifies the download time for the full HTML document, making incremental streaming gains visible.

Interaction to Next Paint (INP) measures the time from any user interaction to the next paint. It replaced FID as a Core Web Vital in 2024. Streaming reduces INP by prioritizing the hydration of interactive components the user is likely to engage with first, reducing the blocking time before those components become responsive.

The highest-impact configuration combines edge rendering (low TTFB from a nearby PoP) with streaming (progressive HTML delivery) and selective hydration (progressive JS processing). Together, these three techniques minimize every major performance metric across the full loading lifecycle.

Which performance metric does React streaming most directly improve for above-fold content?

Streaming most directly improves FCP by delivering the HTML shell immediately, and improves LCP when the LCP element is in the shell. TTI improves through selective hydration spreading JS work over time. TTFB is unchanged — address it with edge rendering. Use WebPageTest filmstrip and Chrome DevTools throttling to measure streaming impact, and optimize for INP as the primary interactivity metric in Core Web Vitals.