Voici une petite introduction pour comprendre le rendu côté client (Client-Side Rendering (CSR)) versus Rendu côté serveur (Server-Side Rendering (SSR))
Dans mon expérience de codage jusqu’à présent, je trouve que les mots rendus côté client et côté serveur sont régulièrement utilisés. J’ai l’impression de comprendre intuitivement certains aspects de ces deux termes et ils me semblent assez clairs, mais j’ai voulu prendre le temps de fouiller un peu et de dévoiler plus clairement ce qu’ils sont, et à quoi ressemblent leurs utilisations ! C’est parti !
Qu’est-ce que le Client-Side Rendering (CSR) ?
- Votre requête initiale charge la page, la mise en page, le CSS, le JavaScript(JS).
- Une partie ou la totalité du contenu est incluse : au lieu de cela, JS fait une autre demande, obtient une réponse (probablement en JSON) et génère le HTML approprié (généralement à l’aide d’une bibliothèque de templating comme React).
- Pour les mises à jour ultérieures de la page, l’approche côté client répète le même processus.
Exemple de cycle de vie d’un CSR :
- Le serveur envoie la réponse au navigateur.
- Le navigateur télécharge le JS.
- Le navigateur exécute React =>> la page est maintenant visible et interactive.
Qu’est-ce que le Server-Side Rendering (SSR) ?
- Avec le rendu côté serveur, votre demande initiale charge la page, la mise en page, les CSS, les JS et le contenu (HTML).
- Les mises à jour côté serveur ne signifient pas nécessairement un rafraîchissement de la page, mais plutôt une mise à jour partielle, le serveur se chargeant du rendu et de l’insertion de la sortie finalisée dans le DOM.
Exemple de cycle de vie SSR :
- Le serveur envoie au navigateur une réponse HTML prête à être rendue.
- Le navigateur effectue le rendu de la page, qui est maintenant visible, et télécharge JS.
- Le navigateur exécute React => la page est maintenant interactive.
Les inconvénients du rendu côté client
- Vous comptez sur le fait que l’utilisateur dispose d’un ordinateur rapide capable de supporter le moteur du navigateur qui fait le gros du travail.
- Le chargement initial peut prendre plus de temps, mais le résultat est visible et interactif.
- Le client est plus lent que le côté serveur parce qu’il faut télécharger plus de Javascript, il y a donc plus de JS à analyser, il faut une deuxième requête HTTP pour charger le contenu et ensuite plus de JS pour générer le modèle.
- Moindre référencement si elle n’est pas mise en œuvre correctement.
- Dans la plupart des cas, nécessite une bibliothèque externe.
Les points négatifs du rendu côté serveur
- Requêtes fréquentes du serveur qui peuvent provoquer un engorgement des sites très interactifs.
- Lenteur générale du rendu des pages (rechargements complets des pages).
- Interactions de site non riches.
Les avantages du rendu côté client
- Interactions riches sur le site.
- Rendu rapide du site après le chargement initial.
- Idéal pour les applications Web.
- Sélection robuste de bibliothèques JS.
- L’application est plus réactive et les utilisateurs ne voient pas le flash entre les navigations de page en raison des rafraîchissements de la page entière.
- Séparation claire des préoccupations entre le client et le serveur ; vous pouvez facilement construire de nouveaux clients pour différentes plateformes (par exemple, mobile, chatbots, smartwatches) sans avoir à modifier le code du serveur. Vous pouvez également modifier la pile technologique sur le client et le serveur indépendamment, tant que le contrat API n’est pas rompu.
Les avantages du rendu côté serveur
- Notre vue s’affiche un peu avant que la page ne devienne interactive.
- La réponse du serveur au navigateur est le HTML de votre page qui est prêt à être rendu.
- Excellent pour l’optimisation des moteurs de recherche (SEO). Votre contenu est présent avant que vous ne l’obteniez, ce qui permet aux moteurs de recherche de l’indexer et de l’explorer efficacement.
- Le chargement initial de la page est plus rapide.
- La page blanche qui peut se produire avec CSR ne se produit pas avec SSR.
- Idéal pour les sites statiques (par exemple, le New York Times, les sites contenant beaucoup de données).
- Les moteurs de recherche peuvent explorer le site pour un meilleur référencement.
Cas d’utilisation
Quand utiliser SSR
- Si vous avez besoin de référencement sur les moteurs de recherche comme Yahoo, etc.
- Vous avez déjà une application react qui fonctionne, vous avez besoin des meilleures performances possibles et vous êtes prêt à payer pour les ressources supplémentaires du serveur.
- Bon usage pour une application web à fort contenu textuel comme un site d’information (New York Times).
N’utilisez pas SSR
- Si votre application React n’est pas encore terminée, commencez par la faire fonctionner.
- Le référencement de base sur Google est suffisant (assurez-vous que Google explore votre contenu).
- Les ressources du serveur sont rares, peut-être en raison d’un faible budget ou d’une incapacité à évoluer.
Bienvenue dans le futur (hybride)
Aucun des deux types de composants n’est une solution en soi. Les composants côté serveur exigent un effort supplémentaire en matière de style et d’interactivité qui semble inutile lorsque l’on considère les offres des composants clients. Mais les composants clients ont tendance à réduire les performances du front-end. Et comme le succès d’un site Web dépend souvent de l’engagement de l’utilisateur, un manque de performance peut nuire au résultat final et suffire à ne pas vouloir utiliser les composants client.
Qu’est-ce que cela signifie pour un avenir qui exige à la fois des performances et une bonne expérience pour les développeurs ? Plus que probablement, une approche hybride.
Les composants vont devoir être rendus côté serveur. C’est ainsi. C’est ainsi que nous optimisons les performances, et de bonnes performances continueront d’être un attribut des sites Web performants. Mais, maintenant que nous avons vu la facilité de la logique et de l’interactivité frontales à l’aide de frameworks, comme React et Vue, ces frameworks sont là pour rester (du moins pour un certain temps).
Alors, où allons-nous ?
Je pense que nous allons voir ces composants s’associer de trois façons dans un avenir très proche.
1. Progrès des frameworks JavaScript
Vous vous souvenez de ce spoiler sur le pré-rendu ? Eh bien, parlons-en maintenant.
Des frameworks comme Gatsby, Next et Nuxt agissent comme des moteurs front-end construits au-dessus de frameworks de composants, comme React et Vue. Ils regroupent des outils permettant de créer une expérience front-end complète à l’aide de leur framework préféré. L’une de ces fonctionnalités est le pré-rendu, ce qui signifie que ces moteurs analyseront les composants et écriront ensuite du HTML statique sur la page pendant la construction du site. Ainsi, lorsque les utilisateurs consultent la page, celle-ci est déjà présente. Ils n’ont pas besoin de JavaScript pour l’afficher.
Cependant, JavaScript entre en jeu par le biais d’un processus appelé hydratation. Une fois que la page est chargée et que l’utilisateur voit tout le contenu (statique), c’est là que JavaScript se met au travail. Il prend en charge les composants pour les rendre interactifs. Cela permet de créer un site Web côté client, basé sur des composants, tout en bénéficiant de certains des avantages du serveur, à savoir les performances et le référencement.
Ces outils sont devenus très populaires grâce à cette approche, et je pense qu’ils vont continuer à progresser. Par exemple, j’ai batit un petit site avec Next jesuisun.dev pour faire une preuve de concept avec cet outil. Et présentement, le SEO est parfait, l’affichage est super rapide. En plus d’avoir une note excellente pour Google Lighthouse
Selon moi, NextJS est le meilleur frameworks de rendu côté serveur pour les implémentations futures. Il est l’un des frameworks React dont la croissance est la plus rapide avec une communauté solide. En plus le titre du site est simplement « The React Framework for Production ». En plus, il offre de nombreuses fonctionnalités intégrées et vous n’avez pas à vous soucier du regroupement, de la minification ou du rechargement à chaud. Vous êtes en mesure de créer des pages en tant que composants React dans des fichiers.
2. Pré-rendu côté client intégré.
Cela fait beaucoup de mots composés.
Ce à quoi j’ai beaucoup réfléchi ces dernières années est le suivant : Pourquoi React (ou Vue) ne prend pas en charge le rendu côté serveur ? Ils le font, mais ce n’est pas très facile à comprendre ou à mettre en œuvre sans l’aide d’un autre framework.
D’un côté, je comprends le principe de responsabilité unique, et que ces frameworks de composants sont juste des moyens de construire des composants côté client. Mais j’ai ressenti comme un énorme manquement le fait de déléguer le rendu côté serveur à des outils plus grands et plus complexes comme Gatsby et Next (entre autres).
Eh bien, React a commencé à évoluer dans ce sens. Vue est déjà là. Et Svelte a fait de cette approche une priorité dès le début.
Je pense que nous allons voir beaucoup plus de développement pendant que ces outils traditionnellement centrés sur le client résolvent le rendu côté serveur. Je soupçonne que cela signifie également que nous entendrons un peu plus parler de Svelte à l’avenir, qui semble être en avance sur le jeu à cet égard.
Cela peut également conduire au développement de plus de concurrents aux outils plus volumineux comme Gatsby et Next. Par exemple, regardez ce que Netlify fait avec son site Web. Il s’agit d’un projet Eleventy qui récupère les composants Vue et les rend utilisables sur le serveur. Ce qui lui manque, c’est l’hydratation et l’interactivité. Je m’attends à ce que cela se fasse dans un avenir très proche.
3. Interactivité des composants côté serveur
Nous ne pouvons pas non plus négliger l’utilisation continue des composants côté serveur. L’un des effets secondaires des deux autres progrès est qu’ils utilisent toujours des cadres JavaScript qui peuvent sembler inutiles lorsque vous n’avez besoin que d’un peu d’interactivité.
Il doit y avoir un moyen plus simple d’ajouter un peu de JavaScript pour rendre plus interactif un composant côté serveur écrit dans un langage côté serveur.
Résoudre ce problème semble être l’approche des gens de Basecamp, qui ont publié Hotwire, qui est un moyen d’apporter certains des avantages des composants clients au serveur, en utilisant (presque) n’importe quel langage côté serveur.
Je ne sais pas si cela signifie que nous allons voir émerger tout de suite une concurrence à Hotwire. Mais je pense que Hotwire va attirer l’attention. Et cela pourrait bien ramener les gens à travailler avec des frameworks monolithiques complets comme Rails.
4. Services de Prerendering
Aussi des services comme Prerender.io, Pupeteer ou Rendertron utilisent un navigateur sans header pour charger toutes vos ressources dans un code HTML statique dont les robots pourront profiter.
Cette approche vous permet de continuer à construire votre site en utilisant les derniers frameworks JavaScript comme React, Ember et Angular et de ne pas avoir à vous reposer sur une solution de rendu de serveur. Le principal avantage de ces outils est de ne pas supporter la charge (conséquente) d’un rendering en local.
Un avantage contrebalancé par deux inconvénients majeurs, notamment pour Prerender.io, qui est un SaaS. En effet, en utilisant cette solution, le site devient dépendant à 100% d’un service externe pour sa disponibilité. Autre point faible de la solution, si les pages doivent être générées à la volée, le service peut être ralenti, car le rendering se fait sur un serveur distant » indique l’expert. À l’inverse, Rendertron s’opère en interne, ce qui replace la dépendance à l’outil en interne, mais oblige le site à supporter la charge du pre-rendering.
Voici une citation que j’ai trouvée sur le site openclassrooms qui est vraiment important de comprendre.
Cependant, faites attention au cloaking. Les utilisateurs réels et les bots reçoivent un contenu différent. Cette méthode pourrait être proche du cloaking (technique utilisée par les black hats pour optimiser leur positionnement). Veillez donc à ce qu’il n’y ait pas de différence de contenu entre vos pages prérendues et vos pages normales.
Quelques exemples de pre-rendering:
Conclusion
Ma plongée dans l’apprentissage de la CSR et de la SSR m’a appris que, pour décider des options, il faut évaluer chaque situation et peser les besoins de votre projet, ce n’est certainement pas une décision en noir et blanc.
Je dirai que d’après ce que j’ai lu, je sens que la SSR est plus bénéfique pour l’expérience globale de l’utilisateur surtout avec le référencement. Le CSR repose sur le fait que l’utilisateur dispose d’un ordinateur rapide et d’une bonne connexion Internet, ce qui n’est pas toujours le cas pour certains utilisateurs.
Bien sûr, il y aura toujours des avantages et des inconvénients !
Qu’en pensez-vous ? Penchez-vous pour l’un (CSR) plutôt que pour l’autre (SSR) ?
