Streamet SSR fra edge

Når en server streamer HTML, modtager og gengiver browseren indhold i stykker i stedet for at vente på hele dokumentet. Det betyder, at brugere kan se og interagere med de synlige dele af siden — sidehovedet, navigationen og hero-sektionen — mens langsommere sektioner, der afhænger af data, stadig indlæses.

Hvis du sender bootstrapScripts til renderToReadableStream, fortæller du React, hvor klientens JS-pakke ligger. React indsætter et script-tag i slutningen af streamen, så browseren indlæser pakken og kalder hydrateRoot, hvilket gør siden interaktiv, efterhånden som hver sektion er færdig med at blive sendt som en strøm.

React's streaming er afhængig af Suspense-grænser til at opdele komponenttræet i sektioner, der kan sendes som separate strømme. Komponenter inde i en Suspense-grænse, som venter på data (via et Promise, der kastes), sendes først som pladsholdere og løses derefter, hvorefter deres rigtige indhold sendes.

onShellReady-callbacken udløses, når HTML-skallen uden Suspense — alt uden for Suspense-grænserne — er klar til at blive sendt som en strøm. Det er det rigtige tidspunkt at angive HTTP-statuskoden og svarheaderne og derefter kalde pipe(res) eller begynde at læse fra ReadableStream.

HTTP-statuskoder og headere skal sendes, før svarlegemet begynder. Fordi streaming begynder med onShellReady, skal al fejlhåndteringslogik (angivelse af status 500, omdirigering) køre, før skallen begynder at flyde — når streaming først er begyndt, er statuskoden låst.

onShellError udløses, når der opstår en fatal fejl, før skallen er klar — f.eks. en fejl i en komponent på øverste niveau uden for en Suspense-grænse. I så fald sendes skallen aldrig, og du bør svare med en statisk fejlside eller omdirigere til en fejlrute.

onError udløses ved fejl, der kan genoprettes fra, inden for Suspense-grænser. React kan stadig sende resten af siden som en strøm; den grænse, hvor fejlen opstod, gengiver sin reservebrugerflade til fejl. Brug onError til logning: registrer fejlen på din overvågningsplatform uden at afbryde strømmen.

Hvis dataene for en Suspense-grænse tager for lang tid, skal du streame skallen alligevel og lade grænsen blive hydreret på klienten. Implementér en tidsgrænse: Efter 5 sekunder skal du kalde abort() for streamen, hvis grænsen ikke er blevet afklaret, hvorefter klienten selv henter dataene via useEffect.

Workers-runtimeet videregiver ReadableStream direkte som Response-bodyen. Cloudflares infrastruktur videresender hver blok til brugerens browser, efterhånden som React producerer den, uden at buffere hele dokumentet. Det betyder, at de første HTML-bytes forlader edge-PoP'en inden for millisekunder efter, at anmodningen ankommer.

renderToReadableStream returnerer en funktion til afbrydelse. Hvis anmodningen annulleres (brugeren navigerer væk), stopper et kald til abort() React i at fortsætte med at gengive og behandle data. Det forhindrer spildt beregning på forladte anmodninger og holder Workerens CPU-forbrug begrænset.

Med streaming ved edge ser hele latenskæden sådan ud: 5 ms (anmodning til nærmeste PoP) + 2 ms (kold opstart af Worker) + 8 ms (gengivelse af skallen) = 15 ms til første byte. Brugerens browser gengiver LCP-elementet fra skallen, mens resten af siden fortsætter med at blive streamet i baggrunden.

Streaming-SSR fra edge leverer HTML i blokke, hvilket forbedrer FCP og LCP ved at sende skallen med det samme. Suspense-grænser opdeler træet i sektioner, der kan streames uafhængigt af hinanden. onShellReady er signalet til at begynde videresendelsen — angiv statuskoder, før du kalder den. onShellError håndterer fatale fejl, onError håndterer fejl, der kan genoprettes fra, og abort() forhindrer spildt arbejde på annullerede anmodninger.