Next.js: Rendu de flux pour réduire la charge TTFB et CPU

Une chose à mentionner..

Le rendu de flux n'ajoute généralement pas beaucoup d'améliorations au processeur, car la quantité de travail à effectuer est la même. Mais cela réduira le temps de réponse.

C'est une très bonne idée de fournir un moyen de personnaliser le système de rendu SSR. Mais je pense que pour l'instant, nous nous en tiendrons aux méthodes renderToString() de React par défaut.

C'est quelque chose que nous pourrions faire après 2.0.

Le rendu de flux n'ajoute généralement pas beaucoup d'améliorations au processeur, car la quantité de travail à effectuer est la même.

_de aickin/react-dom-stream _

Un appel à ReactDOM.renderToString peut dominer le CPU et affamer d'autres requêtes. Ceci est particulièrement gênant sur les serveurs qui servent un mélange de petites et grandes pages.

Le streaming ne réduirait-il pas sensiblement l'allocation de mémoire et l'utilisation du processeur pour les grandes pages en étant à la fois asynchrone et partiel ?

Je pensais que c'était dans le même sens. Quelqu'un a-t-il essayé https://github.com/FormidableLabs/rapscallion ?

Il fournit une interface de streaming afin que vous puissiez commencer à envoyer du contenu au client immédiatement.

Autres fonctionnalités de la doc :

• Le rendu est asynchrone et non bloquant.
• Rapscallion est environ 50 % plus rapide que renderToString.
• Il fournit une interface de streaming afin que vous puissiez commencer à envoyer du contenu au client immédiatement.
• Il fournit une fonctionnalité de modèle, de sorte que vous pouvez envelopper le code HTML de votre composant dans un passe-partout sans renoncer aux avantages du streaming.
• Il fournit une API de mise en cache des composants pour accélérer davantage votre rendu.

Ajout d'un exemple de Rapscallion dans #2279... peut confirmer que Rapscallion + Next est fou. Le rendu en streaming/basé sur les promesses est génial, mais la mise en cache au niveau des composants change la donne pour nous... :godmode:

Maintenant que React 16 a son propre renderToNodeStream , ce serait un énorme avantage pour next.js d'ajouter une option pour l'utiliser au lieu de renderToString . Qu'en pensez-vous, @timneutkens ?

C'est déjà sur notre liste de choses à ajouter

Des nouvelles à ce propos?

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

Des nouvelles?

Next.js doit exposer render (avec renderToString comme moteur de rendu par défaut) pour que l'utilisateur puisse utiliser son moteur de rendu asynchrone personnalisé, je pense.
L'absence de cette fonctionnalité m'a forcé à utiliser razzle pour utiliser un moteur de rendu asynchrone :( (son DX est loin d'être NextJS, mais j'ai dû l'accepter pour continuer).

J'aime tout sur Next.js sauf deux choses :

• Moteur de rendu asynchrone personnalisé.
• Configuration babel personnalisée pour le serveur et le client.

une feuille de route/plan de prise en charge du rendu en streaming ? donc attendu avoir ceci dans next.js .

Le est en attente de l'équipe React mettant en œuvre React Fizz / leur plan pour cela.

@timneutkens Quel est le problème, les relations publiques à suivre ici ?

Extrait de l'article de blog de Facebook, publié le 8 août 2019
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Une mise à jour sur le rendu du serveur
Nous avons commencé à travailler sur le nouveau moteur de rendu du serveur compatible Suspense, mais nous ne nous attendons pas à ce qu'il soit prêt pour la version initiale du mode simultané. Cette version fournira cependant une solution temporaire qui permet au moteur de rendu du serveur existant d'émettre immédiatement du code HTML pour les secours Suspense, puis de restituer leur contenu réel sur le client. C'est la solution que nous utilisons actuellement chez Facebook jusqu'à ce que le moteur de rendu en continu soit prêt.

Pour tous ceux qui attendent encore le support du streaming du serveur :)

Existe-t-il une mise à jour ou une autre méthode pour implémenter renderToNodeStream dans next.js ?

Y a-t-il une mise à jour?

<3

Toute mise à jour?

@StarpTech Je l' avais regardé un peu dans ce (curieux pour cette fonction aussi bien!) Et il semble que l'équipe travaille réagir sur ce qu'on appelle réagir vol , ce qui sera probablement la base pour la solution de streaming que nous attendons ici :)

réaction-vol :

Il s'agit d'un package expérimental permettant de consommer des modèles de streaming React personnalisés.

Les relations publiques pertinentes qui mettent en lumière le fonctionnement interne, interprétées par moi (pas un expert dans tout cela 🙈 )
#17285 : API de base pour le vol, le serveur devrait pouvoir tout diffuser sous forme de chaîne, mais laisser des espaces réservés pour les morceaux qui sont résolus de manière asynchrone sur le serveur. Une syntaxe incomplète, mais intéressante, pour savoir comment réagir pourrait savoir à partir d'un flux quel type de données il représente réellement est ici .

#17398 PR plus récent, ajoute une API pour Chunks donc (si vous vous sentez chanceux), vous pouvez essayer cette partie vous-même. Je ne sais pas comment tout se déroulerait mais néanmoins je suis plutôt content de voir tout ce travail se faire :)

_Cela peut être légèrement hors sujet, mais j'espère intéressant pour les personnes qui s'abonnent à ce numéro :)_

@pepf merci pour l'info !

Hum. Merci à tous les gars, info intéressante. Je me demande juste pourquoi NextJS devrait-il attendre le support SSR de React pour le suspense et tout ça, et pas seulement utiliser streamAsString maintenant ?

@arunoda Je pense que cela réduira la consommation de mémoire, très important pour les fonctions lambda à faible mémoire ou les Cloudflare Workers.

Des nouvelles à ce propos?

Des nouvelles?

Des nouvelles les gars ? :P

Étant donné que le suspense réactif donne l'impression qu'il ne sortira peut-être jamais, y a-t-il un moyen de revoir cela? Je vois des temps de rendu initiaux de 800 à 1000 ms sur des pages assez génériques et à faible contenu (qui sont rendues à partir d'une fonction sans serveur sur vercel). Le streaming du HTML en théorie pourrait augmenter ce point de contact initial et conduire à un ux de premier chargement perçu beaucoup plus rapidement.

Est-ce une limitation de Vercel plutôt que NextJS ? Vercel est-il victime du même type de démarrage à froid que Lambda ? Mon équipe gère un tas de sites riches en contenu et nos délais sont inférieurs à 50 ms pour l'ensemble de la demande. Je ne pense pas que le streaming sera une solution miracle ici.

Je ne m'attends pas à ce que ce soit une solution miracle, mais ce serait certainement une amélioration bienvenue.

50 ms semblent minuscules et relativement trop insignifiants pour être optimisés par rapport aux temps de démarrage à froid mentionnés, mais ce n'est pas le cas lors du rendu à la périphérie avec quelque chose comme Cloudflare Workers (c'est autant que le ping vers l'emplacement périphérique Cloudflare le plus proche, ou au moins la moitié ), Cloudflare Workers répond très rapidement, généralement en moins de 5 millisecondes, lors d'un démarrage à froid. En revanche, les fonctions Lambda et Lambda@Edge peuvent prendre plus d'une seconde pour répondre à partir d'un démarrage à froid.
Je sais que cela ne fait pas un meilleur cas pour Varcel (qui construit son propre cdn) a employé les développeurs de next.js pour donner la priorité à cela.

Existe-t-il de la documentation ou des référentiels où les gens ont déployé avec succès next.js sur les travailleurs cloudflare ? J'ai fait quelques recherches sur Google et je n'ai pas trouvé grand chose dessus. Ce serait génial.

Envoyé depuis mon téléphone

Le 5 juillet 2020 à 17h47, Wis [email protected] a écrit :

50 ms semblent vraiment faibles et relativement insignifiants à optimiser par rapport aux temps de démarrage à froid mentionnés, mais 50 ms, c'est beaucoup lors du rendu à la périphérie avec quelque chose comme Cloudflare Workers (c'est autant que le ping vers l'emplacement périphérique Cloudflare le plus proche, ou au moins la moitié), Cloudflare Workers répond très rapidement, généralement en moins de 5 millisecondes, lors d'un démarrage à froid. En revanche, les fonctions Lambda et Lambda@Edge peuvent prendre plus d'une seconde pour répondre à partir d'un démarrage à froid.
Je sais que cela ne fait pas un meilleur cas pour Varcel (qui construit son propre cdn) a employé les développeurs de next.js pour donner la priorité à cela.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désabonnez-vous.

50 ms semblent minuscules et relativement trop insignifiants pour être optimisés par rapport aux temps de démarrage à froid mentionnés

Pour clarifier, je ne me plaignais pas de mes temps de réponse de 50 ms - je soulignais simplement que le SRR de NextJS est relativement performant même au nord de 3 000 requêtes / minute pour les pages à contenu important, donc le problème de Switz pourrait résider ailleurs.

Existe-t-il de la documentation ou des référentiels où les gens ont déployé avec succès next.js sur les travailleurs cloudflare

ça m'intéresserait aussi. Nous fonctionnons actuellement dans Fargate, mais pousser notre application vers le bord serait la prochaine étape logique.

J'ai apporté toutes les améliorations possibles à mon code HTML et le temps de réponse du serveur est fulgurant ! :(

@huggler, vous pouvez combiner cet exemple avec cacheable-response . Vous pouvez utiliser Redis (ou un cache en mémoire par exemple) pour stocker du html dans le cache. Il améliore le temps de réponse du serveur.

Existe-t-il de la documentation ou des référentiels où les gens ont déployé avec succès next.js sur les travailleurs cloudflare ? J'ai fait quelques recherches sur Google et je n'ai pas trouvé grand chose dessus. Ce serait génial.

@switz @tills13 avez-vous https://fab.dev/ ? Nous avons joué avec lui début 2020 et il était en état de pré-sortie, mais ils semblent être allés assez loin. L'une de leurs limitations était Cloudflare lui-même, mais les choses ont peut-être changé maintenant.

Je n'ai pas regardé depuis un moment. Faudrait réévaluer. La dernière fois que j'ai regardé, il y avait des compromis assez sérieux.

Je garde également un œil sur https://github.com/flareact/flareact.

Une mise à jour pour ceci?