Mäta effekten av strömning: FCP, TTI och LCP

FCP mäter tiden från navigeringens början tills den första innehållsdelen (text, bild eller bakgrund) målas upp på skärmen. Streaming förbättrar FCP genom att skicka HTML-skalet omedelbart – webbläsaren kan måla upp layouten, navigeringen och eventuell text i den första viewporten så snart de första delarna anländer.

Med synkron SSR (renderToString) får webbläsaren ingen HTML förrän hela renderingen är klar. Med streaming får webbläsaren HTML-skalet inom millisekunder från begäran – layouten och det statiska innehållet visas nästan omedelbart, vilket minskar FCP avsevärt.

LCP mäter när det största synliga elementet i viewporten målas upp – vanligtvis en hero-bild eller en stor rubrik. Streaming förbättrar LCP om LCP-elementet ingår i skalet (och inte ligger i en Suspense-gräns), eftersom skalet streamas före alla databeroende avsnitt.

En viktig optimering är att utforma sidan så att LCP-elementet – hero-sektionen, huvudrubriken eller den utvalda bilden – ligger utanför alla Suspense-gränser. Om LCP-elementet ligger i en Suspense-gräns som väntar på data kan streaming inte förbättra LCP förrän dessa data har lösts upp.

TTI mäter när sidan på ett tillförlitligt sätt svarar på användarindata – utan Long Tasks som blockerar huvudtråden. Streaming i kombination med selektiv hydrering minskar TTI genom att sprida ut hydreringarbetet över tid i stället för att köra en stor synkron hydrering efter att all JavaScript har laddats ned.

Time to First Byte (TTFB) avgörs av nätverkslatens och serverns bearbetningstid innan den första byten skickas. Streaming ändrar inte TTFB – det är där edge-rendering hjälper. För att streaming ska förbättra FCP behöver du först en låg TTFB; annars streamar du bara från en långsam ursprungsserver.

WebPageTests filmstrip-vy visar en sekvens med skärmbilder som tas var 100:e millisekund under sidladdningen. På en sida med streaming visas layouten tidigt och sektionerna fylls sedan i stegvis. På en sida utan streaming visas först en tom skärm, följt av en plötsligt fullständigt renderad sida – en tydlig visuell skillnad.

Ett meningsfullt benchmark jämför samma sida renderad på två sätt: med streaming aktiverat för Next.js RSC jämfört med traditionell synkron SSR. Använd WebPageTest med en fast nätverksprofil, till exempel Fast 3G och 4× CPU-fördröjning, och jämför mätvärdena FCP, LCP och TTI över tre testkörningar för statistisk tillförlitlighet.

Fliken Network i Chrome DevTools har en rullgardinsmeny kallad "Throttling" med förinställningar som Fast 3G och Slow 4G. Fast 3G (1.6 Mbps, 150ms RTT) förstärker skillnaden mellan streaming och icke-streaming, eftersom nedladdningstiden för hela HTML-dokumentet blir längre och vinsterna med stegvis streaming därmed blir synliga.

Interaction to Next Paint (INP) mäter tiden från en användarinteraktion till nästa rendering. Det ersatte FID som ett Core Web Vital-mätvärde 2024. Streaming minskar INP genom att prioritera hydreringen av interaktiva komponenter som användaren sannolikt först kommer att interagera med, vilket minskar blockeringstiden innan komponenterna blir responsiva.

Den konfiguration som ger störst effekt kombinerar edge-rendering, med låg TTFB från en närliggande PoP, med streaming, alltså stegvis HTML-leverans, och selektiv hydrering, alltså stegvis JavaScript-bearbetning. Tillsammans minimerar dessa tre tekniker alla större prestandamått under hela laddningsförloppet.

Streaming förbättrar FCP mest direkt genom att leverera HTML-skalet omedelbart och förbättrar LCP när LCP-elementet finns i skalet. TTI förbättras genom selektiv hydrering, som fördelar JavaScript-arbetet över tid. TTFB förblir oförändrat – åtgärda det med edge-rendering. Använd WebPageTests filmstrip-vy och Chromes DevTools för nätverksbegränsning för att mäta streamingens effekt, och optimera INP som det primära interaktivitetsmätvärdet i Core Web Vitals.