Next.js: Stream-Rendering zur Reduzierung der TTFB- und CPU-Last

Eine Sache zu erwähnen..

Stream-Rendering bringt normalerweise keine großen CPU-Verbesserungen, da der Arbeitsaufwand gleich ist. Aber es verkürzt die Reaktionszeit.

Es ist eine ziemlich gute Idee, eine Möglichkeit zum Anpassen des SSR-Renderingsystems bereitzustellen. Aber ich denke, vorerst bleiben wir standardmäßig bei den renderToString()-Methoden von React.

Dies ist etwas, was wir nach 2.0 tun könnten.

Stream-Rendering bringt normalerweise keine großen CPU-Verbesserungen, da der Arbeitsaufwand gleich ist.

_von aickin/react-dom-stream _

Ein Aufruf von ReactDOM.renderToString kann die CPU dominieren und andere Anforderungen aushungern. Dies ist besonders auf Servern problematisch, die eine Mischung aus kleinen und großen Seiten bereitstellen.

Würde Streaming die Speicherzuweisung und die CPU-Auslastung für große Seiten nicht sinnvoll reduzieren, indem es sowohl asynchron als auch partiell ist?

Dachte das geht in die gleiche Richtung. Hat jemand https://github.com/FormidableLabs/rapscallion versucht?

Es bietet eine Streaming-Schnittstelle, sodass Sie sofort mit dem Senden von Inhalten an den Client beginnen können.

Weitere Funktionen aus den Dokumenten:

• Das Rendern ist asynchron und nicht-blockierend.
• Rapscallion ist ungefähr 50 % schneller als renderToString.
• Es bietet eine Streaming-Schnittstelle, sodass Sie sofort mit dem Senden von Inhalten an den Client beginnen können.
• Es bietet eine Vorlagenfunktion, mit der Sie den HTML-Code Ihrer Komponente in Boilerplate einschließen können, ohne auf die Vorteile des Streamings verzichten zu müssen.
• Es bietet eine Komponenten-Caching-API, um Ihr Rendering weiter zu beschleunigen.

Ein Beispiel für Rapscallion in #2279 hinzugefügt ... kann bestätigen, dass Rapscallion + Next verrückt ist. Gestreamtes/versprechensbasiertes Rendern ist großartig, aber Caching auf Komponentenebene ist ein Game-Changer für uns... :godmode:

Da React 16 nun ein eigenes renderToNodeStream , wäre es für next.js ein großer Vorteil, eine Option hinzuzufügen, um es anstelle von renderToString . Was meinst du, @timneutkens?

Es steht bereits auf unserer Liste der Dinge, die wir hinzufügen können 👍

Irgendetwas Neues darüber?

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

Irgendwelche Neuigkeiten?

Next.js muss benutzerdefinierte render (mit renderToString als Standard-Renderer) verfügbar machen, damit der Benutzer seinen benutzerdefinierten asynchronen Renderer verwenden kann, denke ich.
Das Fehlen dieser Funktion zwang mich jedoch, razzle zu verwenden, um einen asynchronen Renderer zu verwenden :( (seine DX ist bei weitem nicht in der Nähe von NextJS, aber ich musste das akzeptieren, um fortzufahren).

Ich liebe alles an Next.js, außer zwei Dingen:

• Benutzerdefinierter asynchroner Renderer.
• Benutzerdefinierte Babel-Konfiguration für Server und Client.

Gibt es eine Roadmap / einen Plan für die Unterstützung von Streaming-Rendering? so erwartet haben dies in next.js .

Das React-Team steht noch aus, um React Fizz / seinen Plan dafür umzusetzen.

@timneutkens Was ist das Problem, PR hier zu verfolgen?

Aus Facebooks Blogbeitrag, veröffentlicht am 8. August 2019
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Ein Update zum Server-Rendering
Wir haben mit der Arbeit am neuen Suspense-fähigen Server-Renderer begonnen, aber wir erwarten nicht, dass er für die erste Veröffentlichung des Concurrent Mode bereit ist. Diese Version wird jedoch eine temporäre Lösung bereitstellen, die es dem vorhandenen Server-Renderer ermöglicht, sofort HTML für Suspense-Fallbacks auszugeben und dann ihren echten Inhalt auf dem Client zu rendern. Dies ist die Lösung, die wir derzeit bei Facebook selbst verwenden, bis der Streaming-Renderer fertig ist.

Für alle, die noch auf Server-Streaming-Unterstützung warten :)

Gibt es ein Update oder eine andere Methode zum Implementieren von renderToNodeStream in next.js?

Gibt es Neuigkeiten dazu?

<3

Irgendein Update?

@StarpTech Ich hatte sah (wie auch neugierig für diese Funktion!) Ein wenig in diesem und es sieht aus wie das Team reagieren arbeitet genannt auf etwas reagieren Flugs , die wahrscheinlich die Basis für die Streaming - Lösung werden wir hier warten :)

Reaktionsflug:

Dies ist ein experimentelles Paket zum Konsumieren benutzerdefinierter React-Streaming-Modelle.

Die einschlägigen PR's, die etwas Licht ins Innenleben bringen, interpretiert von mir (kein Experte in all dem 🙈 )
#17285 : Basis-API für den Flug, der Server sollte in der Lage sein, alles als String zu streamen, aber Platzhalter für die Chunks lassen, die auf dem Server asynchron aufgelöst werden. Eine unvollständige, aber interessante Syntax dafür, wie Reagieren aus einem Stream wissen würde, welchen Datentyp er tatsächlich darstellt, ist hier drüben .

#17398 Neuere PR, fügt eine API für Chunks hinzu, damit Sie (wenn Sie Glück haben) diesen Teil selbst ausprobieren können. Ich bin mir nicht sicher, wie alles zusammenkommen würde, aber trotzdem bin ich ein bisschen glücklich darüber, dass all diese Arbeit erledigt wird :)

_Dies ist vielleicht etwas abseits des Themas, aber hoffentlich interessant für Leute, die diese Ausgabe abonnieren :)_

@pepf danke für die Info!

Hm. Danke an alle Jungs, interessante Infos. Ich überlege nur, warum NextJS warten sollte, bis React SSR für Spannung und so unterstützt, und nicht jetzt nur streamAsString verwenden?

@arunoda Ich denke, es wird den Speicherverbrauch reduzieren, sehr wichtig für Lambda-Funktionen mit geringem Speicher oder Cloudflare-Worker.

Irgendetwas Neues darüber?

Irgendwelche Neuigkeiten?

Irgendwelche Neuigkeiten, Jungs? :P

Angesichts der Tatsache, dass sich die Spannung so anfühlt, als würde sie nie herauskommen, gibt es eine Möglichkeit, dies noch einmal zu überdenken? Ich sehe anfängliche Renderzeiten von 800-1000 ms auf ziemlich generischen Seiten mit wenig Inhalt (die von einer serverlosen Funktion auf Vercel gerendert werden). Theoretisch könnte das Streamen des HTML-Codes diesen anfänglichen Kontaktpunkt erhöhen und zu einem viel schneller wahrgenommenen First-Load-UX führen.

Ist das eher eine Einschränkung von Vercel als von NextJS? Fällt Vercel einem ähnlichen Kaltstart zum Opfer wie Lambda? Mein Team betreibt eine Reihe von inhaltsintensiven Websites und unsere Zeitvorgaben für die gesamte Anfrage liegen unter 50 ms. Ich glaube nicht, dass Streaming hier ein Allheilmittel sein wird.

Ich erwarte nicht, dass es ein Allheilmittel ist, aber es wäre sicherlich eine willkommene Verbesserung.

50 ms klingen winzig und relativ zu unbedeutend, um sie im Vergleich zu den genannten Kaltstartzeiten zu optimieren, aber das ist es nicht beim Rendern am Rand mit etwas wie Cloudflare Workers (es ist so viel wie der Ping zum nächsten Cloudflare-Edge-Standort oder mindestens die Hälfte ) reagieren Cloudflare-Worker beim Kaltstart sehr schnell, normalerweise in weniger als 5 Millisekunden. Im Gegensatz dazu können sowohl die Lambda- als auch die Lambda@Edge- Funktionen eine Sekunde benötigen, um nach einem Kaltstart zu reagieren.
Ich weiß, dass dies kein besseres Argument dafür ist, dass Varcel (das seine eigene CDN erstellt) Entwickler von next.js beschäftigt, um dies zu priorisieren.

Gibt es Dokumentationen oder Repositorys, in denen next.js erfolgreich für Cloudflare-Worker bereitgestellt wurde? Ich habe etwas gegoogelt und nicht viel dazu gefunden. Das wäre fantastisch.

Gesendet von meinem Handy

Am 5. Juli 2020 um 17:47 Uhr schrieb Wis [email protected] :

50ms klingt wirklich niedrig und relativ unbedeutend im Vergleich zu den erwähnten Kaltstartzeiten, aber 50ms sind viel beim Rendern am Rand mit etwas wie Cloudflare Workers (es ist so viel wie der Ping zum nächsten Cloudflare-Edge-Standort, oder zumindest Hälfte), Cloudflare-Worker reagieren beim Kaltstart sehr schnell, normalerweise in weniger als 5 Millisekunden. Im Gegensatz dazu können sowohl die Lambda- als auch die Lambda@Edge- Funktionen eine Sekunde benötigen, um nach einem Kaltstart zu reagieren.
Ich weiß, dass dies kein besseres Argument dafür ist, dass Varcel (das seine eigene CDN erstellt) Entwickler von next.js beschäftigt, um dies zu priorisieren.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.

50ms klingt winzig und relativ zu unbedeutend, um im Vergleich zu den genannten Kaltstartzeiten zu optimieren

Um das klarzustellen, ich habe mich nicht über meine 50-ms-Antwortzeiten beschwert - ich habe nur darauf hingewiesen, dass die SRR von NextJS selbst nördlich von 3k Anfragen / Minute für inhaltsreiche Seiten relativ performant ist, also könnte das Problem von Switz woanders liegen.

Gibt es Dokumentationen oder Repositorys, in denen next.js erfolgreich für Cloudflare-Worker bereitgestellt wurde?

das würde mich auch interessieren. Wir laufen derzeit in Fargate, aber es wäre der nächste logische Schritt, unsere App an den Rand zu drängen.

Ich habe alle möglichen Verbesserungen in meinem HTML-Code vorgenommen und die Antwortzeit des Servers ist blitzschnell! :(

@huggler Sie können dieses Beispiel mit cacheable-response kombinieren. Sie können Redis (oder zum Beispiel In-Memory-Cache) verwenden, um HTML im Cache zu speichern. Es verbessert die Antwortzeit des Servers.

Gibt es Dokumentationen oder Repositorys, in denen next.js erfolgreich für Cloudflare-Worker bereitgestellt wurde? Ich habe etwas gegoogelt und nicht viel dazu gefunden. Das wäre fantastisch.

@switz @tills13 hast du dir https://fab.dev/ angesehen ? Wir haben Anfang 2020 damit gespielt und es war im Pre-Release-Zustand, aber sie scheinen ziemlich weit gekommen zu sein. Eine der Einschränkungen hinter ihnen war Cloudflare selbst, aber die Dinge könnten sich inzwischen geändert haben.

Habe schon länger nicht mehr geschaut. Müsste neu bewerten. Als ich das letzte Mal nachgesehen habe, gab es einige ziemlich ernsthafte Kompromisse.

Ich behalte auch https://github.com/flareact/flareact im Auge

Gibt es hierzu Neuigkeiten?