Strömmande SSR från edge

När en server strömmar HTML tar webbläsaren emot och renderar innehåll i delar i stället för att vänta på hela dokumentet. Det innebär att användarna kan se och interagera med de synliga delarna av sidan — sidhuvudet, navigeringen och herosektionen — medan långsammare, databeroende sektioner fortfarande läses in.

Om du skickar bootstrapScripts till renderToReadableStream anger du var klientens JavaScript-paket finns. React infogar en script-tagg i slutet av strömmen så att webbläsaren laddar paketet och anropar hydrateRoot, vilket gör sidan interaktiv allteftersom varje sektion har strömmats klart.

React använder Suspense-gränser för att dela upp komponentträdet i sektioner som kan strömmas oberoende av varandra. Komponenter i en Suspense-gräns som väntar på data (genom att kasta ett Promise) strömmas först som platshållare och får sedan sitt riktiga innehåll strömmat när datan är klar.

Callback-funktionen onShellReady körs när det icke-suspenderade HTML-skalet — allt utanför Suspense-gränserna — är klart att strömmas. Det är rätt tidpunkt att ange HTTP-statuskoden och svarshuvudena och sedan anropa pipe(res) eller börja läsa från ReadableStream.

HTTP-statuskoder och svarshuvuden måste skickas innan svarskroppen börjar. Eftersom strömningen startar med onShellReady måste all felhantering (att ange status 500 eller göra en omdirigering) ske innan skalet börjar flöda — när strömningen väl har börjat är statuskoden låst.

onShellError körs när ett allvarligt fel inträffar innan skalet är klart — till exempel ett fel i en komponent på toppnivå utanför alla Suspense-gränser. I det här fallet strömmas skalet aldrig, och du bör svara med en statisk felsida eller omdirigera till en felrutt.

onError körs vid återställningsbara fel i Suspense-gränser. React kan fortfarande strömma resten av sidan, och den felande gränsen renderar sitt reservgränssnitt för fel. Använd onError för loggning: fånga felet i din observability-plattform utan att avbryta strömmen.

Om data för en Suspense-boundary tar för lång tid ska ni ändå strömma skalet och låta boundaryn hydreras på klienten. Implementera en timeout: efter 5 sekunder anropar ni abort() på strömmen om boundaryn inte har lösts, så hämtar klienten själv data via useEffect.

Workers-körmiljön skickar ReadableStream direkt som Response-body. Cloudflares infrastruktur vidarebefordrar varje chunk till användarens webbläsare i takt med att React producerar den, utan att buffra hela dokumentet. Det innebär att de första HTML-bytena lämnar edge-PoP:en inom millisekunder från att begäran anländer.

renderToReadableStream returnerar en abort-controllerfunktion. Om begäran avbryts (användaren navigerar bort) stoppar ett anrop till abort() React från att fortsätta rendera och bearbeta data. Detta förhindrar onödig beräkning för övergivna begäranden och håller Workers CPU-användning inom en begränsad nivå.

Med edge-strömning ser hela latenskedjan ut så här: 5 ms (begäran till närmaste PoP) + 2 ms (kallstart av Worker) + 8 ms (rendering av skalet) = 15 ms till första byten. Användarens webbläsare renderar LCP-elementet från skalet medan resten av sidan fortsätter att strömmas i bakgrunden.

SSR-strömning från edge levererar HTML i chunkar, vilket förbättrar FCP och LCP genom att skicka skalet omedelbart. Suspense-boundaries delar upp trädet i sektioner som kan strömmas oberoende av varandra. onShellReady är signalen att börja pipea — ange statuskoder innan ni anropar den. onShellError hanterar fatala fel, onError hanterar återställningsbara fel och abort() förhindrar onödigt arbete för avbrutna begäranden.