Rendu côté serveur avec React
Publié: 2021-05-27Un peu de réaction
React est une bibliothèque JavaScript frontale open source, qui est créée et maintenue par la communauté des développeurs Facebook. Il est utilisé pour créer des interfaces utilisateur ou des composants d'interface utilisateur.
Cependant, cette définition pourrait ne pas être complètement compréhensible pour les novices. Nous avons le billet de blog parfait qui vous guide à travers une brève explication de React, jusqu'à une description technique très détaillée de celui-ci, que vous pouvez trouver ici.
Le parcours d'une page Web | Du serveur à votre navigateur
Pour comprendre ce qu'est le rendu côté serveur, il est d'abord important d'avoir un aperçu de la façon dont une page Web apparaît sur votre écran, ce qui est expliqué par le diagramme ci-dessous :

- Chaque fois que vous tapez l'URL d'un site Web ou que vous cliquez sur un lien vers le site Web, votre navigateur envoie une demande pour certains fichiers au serveur approprié, identifié par l'URL.
- Le serveur envoie certains fichiers tels que les fichiers HTML et JavaScript, entre autres, à votre navigateur.
- Votre navigateur télécharge et "rend" ou traite ces fichiers et vous pouvez voir et interagir avec la page Web que vous avez demandée.
Il s'agit d'une très grande simplification excessive du parcours d'une page Web, mais c'est une préface suffisante pour expliquer les différentes sous-étapes et les différentes manières (y compris le rendu côté serveur) d'accomplir cette tâche.
Parcours d'une page Web de rendu côté client "normal"
En approfondissant le processus mentionné dans la section précédente, nous avons une technique connue sous le nom de Client Side Rendering ou CSR, qui est utilisée depuis longtemps pour afficher un site Web sur les écrans des utilisateurs. Ceci est expliqué dans le schéma suivant :

- En tapant l'URL d'un site Web ou en cliquant sur un lien vers le site Web, votre navigateur envoie une demande pour certains fichiers au serveur approprié, identifié par l'URL.
- Le serveur envoie le fichier HTML qui contient les références à d'autres actifs tels que les fichiers image, les fichiers CSS et les fichiers JavaScript.
- Le navigateur envoie à nouveau une requête au serveur et télécharge tous les fichiers, y compris les fichiers CSS et JavaScript référencés dans le fichier HTML.
- Cela peut contribuer à augmenter le temps de chargement d'un site Web si les utilisateurs ont une mauvaise connexion et que le fichier JavaScript est volumineux.
- Une fois ces fichiers téléchargés par le navigateur, le navigateur exécute ensuite le framework ou la bibliothèque (par exemple React) et analyse les fichiers JavaScript, qui sont chargés de rendre la page Web interactive.
- Du point de vue de l'optimisation de la vitesse, ce point dépend de la machine cliente et si le client est un matériel à faible puissance, cela peut prendre beaucoup de temps.
- L'utilisateur voit toujours l'écran de chargement lorsque ces étapes sont en cours
- La page Web est finalement complètement chargée et l'utilisateur peut voir et interagir avec la page Web.
Comme il ressort clairement des étapes mentionnées ci-dessus, du point de vue de l'utilisateur, il ne peut voir et interagir avec le site Web qu'à l'étape finale, une fois que tous les fichiers nécessaires ont été téléchargés et rendus par la machine cliente.
Cela peut prendre énormément de temps car cela dépend des performances de la machine cliente lors de l'exécution du framework et de l'analyse des fichiers JavaScript.
Le parcours de la page Web de rendu côté serveur
Expliquant en une seule ligne, le rendu côté serveur ou SSR est le processus consistant à prendre un site Web de framework JavaScript côté client et à le rendre en HTML et CSS statiques sur le serveur au lieu du client, comme c'était le cas dans CSR.
Vous trouverez ci-dessous une représentation graphique du parcours d'une page Web avec le rendu côté serveur, avec React :

- En tapant l'URL d'un site Web ou en cliquant sur un lien vers le site Web, votre navigateur envoie une demande pour certains fichiers au serveur approprié, identifié par l'URL.
- Le serveur, au lieu de simplement envoyer des fichiers HTML vanille comme dans CSR, rend l'application en chaîne à l'aide de la fonction renderToString importée de react -dom/server
- Celui-ci est ensuite injecté dans le fichier index.html et envoyé au navigateur.
- C'est là que se trouve le nœud du SSR, fonctionnellement parlant, car c'est là que le serveur rend la page, et non la machine cliente.
- Le navigateur affiche ce fichier HTML, ce qui entraîne le remplissage de la vue dans le navigateur.
- Cependant, ce n'est pas encore interactif, mais l'utilisateur peut voir la vue finale de la page Web.
- Le navigateur envoie à nouveau une requête au serveur et télécharge tous les fichiers référencés dans le fichier HTML, y compris les fichiers JavaScript.
- Une fois tous les scripts téléchargés, le composant React est à nouveau rendu sur le client. Cependant, cette fois, il hydrate la vue existante au lieu de l'écraser.
- "Hydrater" une vue signifie qu'elle attache tous les gestionnaires d'événements aux éléments DOM (Document Object Model) rendus, mais conserve les éléments DOM rendus intacts. De cette façon, l'état des éléments DOM est préservé et il n'y a pas de réinitialisation de la vue qui se produit.
- La page Web est enfin complètement chargée et l'utilisateur peut maintenant interagir avec la page qu'il a pu voir à partir de l'étape 3 elle-même.
Ainsi, l'un des plus grands changements visuels du point de vue de l'utilisateur est que la page Web devient "visible" assez rapidement, car le rendu HTML n'est pas très gourmand en ressources, du point de vue du navigateur.

Cela ne rend pas intrinsèquement le chargement de la page plus rapide qu'une application non SSR, mais cela donne aux utilisateurs la vue de la page Web lorsque les fichiers JavaScript sont téléchargés et analysés en arrière-plan, après quoi la page Web devient interactive. Cela signifie que le TTI, c'est-à-dire Time To Interactive (c'est le temps qu'il faut pour que la page web soit complètement interactive à partir du moment où l'utilisateur demande la page web) est un peu plus long que le temps qu'il faut pour que la page web soit visible dans le navigateur.
Ainsi, dans un scénario SSR, pour un premier temps de rendu plus rapide, votre HTML et CSS doivent être significatifs pour les utilisateurs, et JavaScript peut être l'amélioration pour HTML et CSS, puisque son chargement est différé.
Une idée fausse courante sur le fonctionnement de SSR avec React est qu'après chaque changement, comme un utilisateur demandant de nouvelles données, le serveur complète à nouveau toutes les étapes et envoie le fichier HTML avec la nouvelle interface utilisateur au navigateur, mais ce n'est pas le cas. . Seule une mise à jour partielle de la page est effectuée. Bien que le rendu soit effectué par le serveur, la sortie finalisée est insérée dans le DOM en l'hydratant, comme expliqué précédemment.

Rendu côté serveur | Quand et quand ne pas utiliser
- Si vous avez besoin d'un référencement fort, optez pour le SSR car il est plus facile pour les moteurs de recherche d'explorer.
- Pour les sites Web axés sur le contenu et non sur l'interaction, tels que les blogs, les sites Web d'actualités, les sites Web statiques et les sites Web contenant beaucoup de texte, le SSR peut être une aubaine car il chargera le cœur de votre site Web, c'est-à-dire un contenu extrêmement rapide.
- Il faut du temps et des efforts côté serveur pour rendre et générer les fichiers à envoyer au navigateur. Donc, si vous avez un serveur et un budget d'exploitation faibles, il vaut mieux ne pas implémenter SSR car il y aura beaucoup de requêtes envoyées à votre serveur.
- Cependant, avec des fournisseurs tels que Firebase, nous pouvons générer dynamiquement du contenu avec des fonctions cloud et le serveur peut le stocker dans le cache CDN
- Ce que cela ferait, c'est que la prochaine fois que l'utilisateur demande, la génération des fichiers n'est pas refaite par le serveur. Au lieu de cela, il est simplement servi à partir d'un CDN local, ce qui améliore les temps de chargement du point de vue de l'utilisateur tout en utilisant moins de ressources serveur.
En quoi React est-il bon pour la RSS ?
React est un excellent choix pour implémenter SSR car il intègre le concept de DOM virtuel (Document Object Model).
Cela permet aux développeurs de créer une version virtuelle de l'application React et de l'avoir sur le serveur lui-même.
Cela facilite le rendu en HTML à l'aide de la fonction renderToString comme indiqué précédemment, envoyez-le au navigateur afin que le navigateur puisse le rendre assez rapidement et créer une version virtuelle sur la machine cliente.
Ainsi, compte tenu du fait que cette version virtuelle correspond au code HTML que nous avons envoyé depuis le serveur, React ne le restituera pas, ce qui réduira le temps d'interaction (TTI), ce qui se traduira par une page Web à chargement "plus rapide".
SSR, toute la journée, tous les jours !
Nous souhaitons qu'il y ait une solution unique pour tout, mais c'est loin d'être le cas, surtout avec les nouvelles technologies. Bien que la RSS présente des tonnes d'avantages, il existe certains cas, comme indiqué précédemment, pour lesquels la RSS pourrait ne pas être un bon choix ; les sites hautement interactifs en étant à l'avant-garde.
C'est là que Creole Studios entre en jeu. Nous avons un éventail d'experts en technologie, toujours au courant de presque toutes les nouvelles technologies qui apparaissent dans le techverse. Nous comprendrons les besoins de votre entreprise et vous fournirons des solutions personnalisées, qu'il s'agisse d'une application SSR ou CSR, et soyez assuré que vous n'aurez à vous soucier de rien pendant que nous faisons le gros du travail pour vous. Contactez-nous et obtenez vos idées de votre tête dans une application!