SSR vs CSR

Server-Side Rendering (SSR)

Pour la plupart d’entre vous qui avez déjà développé des sites ou applications Web avec des langages comme PHP, ASP.NET, Ruby ou Python, que ce soit à travers des frameworks qui supportent l’architecture MVC comme Laravel, Ruby on Rails ou Django, ou en utilisant la syntaxe de base (dite aussi Vanilla), vous générez souvent les vues de vos applications de manière dynamique. C’est-à-dire, qu’après l’exécution du code sur le serveur, du contenu HTML est généré puis transféré au navigateur de l’utilisateur final. C’est ainsi que la page s’affiche englobant tout le contenu requis.

En fait, même avec l’environnement d’exécution Node.js (en l’occurrence à travers le framework Express), il est possible de créer des vues directement depuis le serveur notamment à travers les moteurs de Template PUG ou EJS, bien qu’à la base, Express est censé être un framework backend qui ne se soucie pas de la manière avec laquelle la page sera présentée sur le client.

Le fait de générer les vues depuis le serveur est connu sous le nom de Server-Side Rendering (ou SSR). Autrement dit, l’interface utilisateur est totalement (ou majoritairement) créée sur le serveur de manière dynamique en y intégrant toutes les ressources nécessaires, y compris les informations qui proviennent de bases de données ou d’API distantes. Donc, on imagine que le navigateur ne fait qu’exécuter ce qu’il a reçu du serveur sans qu’il ait vraiment un rôle crucial dans la façon dont le contenu est présenté. En effet, c’est le serveur qui a décidé de cette présentation.

Bien entendu le SSR présente de nombreux avantages que l’on peut résumer dans les points suivants :

• Chargement initial rapide : en effet, puisque la page est entièrement construite par le serveur, le navigateur l’exécute plus rapidement, améliorant ainsi l’expérience utilisateur, en l’occurrence si la connexion de ce dernier est lente.
• Optimisation pour les moteurs de recherche : là encore, le SSR marque un point, car la page rendue au navigateur peut être optimisée pour le SEO facilitant ainsi son référencement et son positionnement dans les moteurs de recherche.
• Du côté du développeur, le SSR s’avère généralement plus facile à manipuler, car il est relativement simple d’incorporer du code HTML et CSS dans la réponse du serveur, ce qui permet de rendre une page complète du premier coup.

Néanmoins, le SSR présente aussi quelques inconvénients, notamment :

• Charge importante sur le serveur : en effet, en plus de chercher et traiter les données qui proviennent généralement de sources comme les bases de données ou les API, le serveur doit aussi s’occuper de la présentation en mettant en page les données traitées afin de servir une page prête à l’affichage au navigateur, ce qui implique une consommation supplémentaire de ressources du serveur.
• Rechargement exigeant : Si le chargement initial peut être vu comme un avantage surtout vis-à-vis des connexions lentes, le fait de demander une nouvelle page oblige le serveur à refaire tout le cycle décrit précédemment, ce qui peut être exigeant en temps de réponse ainsi qu’en bande passante.
• Interactivité faible : cela joint les deux points que l’on vient de voir. En effet, l’utilisateur ressent un manque de fluidité quand il change de page (en cliquant sur un lien par exemple), car la page demandée met un temps important à se charger, sans parler du fait que dans la plupart des cas, cette dernière est entièrement rechargée, ce qui donne lieu à un scintillement parfois désagréable.
• Couplage étroit : ça signifie que le SSR intègre en même temps les processus front-end et back-end, ce qui rend la maintenance de l’application difficile durant son cycle de vie, car il y a une forte dépendance entre les éléments du front et du back, ce qui peut exiger beaucoup d’ajustements suite à une modification d’une partie du code, sans parler de la réduction de modularité et réutilisabilité des composants de l’application, d’autant plus si on souhaite créer une application mobile qui requière les mêmes données et les mêmes traitements de l’application Web.
• Une bonne maîtrise de la part du développeur : qui doit prendre en main un grand nombre de technologies comme le HTML et CSS avancés, le Javascript, les base de données, un ou plusieurs langages CGI comme PHP ou Perl, sans parler d’autres aspects avancés comme les tests ou la sécurité…

Clien-Side Rendering (CSR)

A l’opposé du Server-Side Rendering, il y a le Client-Side Rendering (ou CSR), qui quant-à-lui, consiste à construire la page dynamiquement par le navigateur, généralement à l’aide du Javascript, après avoir reçu un contenu minimal du serveur.

En d’autres termes, après la réception de la requête du client, le serveur se charge de préparer les données voulues (soit en les cherchant dans une base de données ou une API, ou en les générant dynamiquement en suivant une certaine logique), ensuite, il formate ces données là selon une structure commune, comme XML ou Json qu’il envoie ensuite au navigateur. A partir de ce moment, il incombe au navigateur de présenter les données qu’il a reçu en créant dynamiquement l’UI (ou User Interface) à l’aide du Javascript. Bien entendu, le code Javascript qui assure la création des vues est chargée la toute première fois que le navigateur se connecte au serveur qui héberge le site ou application Web.

Là on voit bien que le font-end et le back-end sont bien séparés et se chargent chacun d’exécuter un traitement dans un périmètre bien défini.

Donc, le CSR présente de nombreux avantages, comme l’interactivité avancée, le chargement rapide du nouveau contenu, sans parler de la page qui n’est plus obligée de se recharger entièrement, ce qui améliore l’expérience utilisateur. Néanmoins, le CSR est quand même truffé de quelques inconvénients, notamment le chargement initial lent. En effet, puisque le navigateur se charger de reconstruire les vues de l’application à l’aide du code Javascript, alors il doit importer tout ce code là lors du premier chargement de l’application, ce qui explique parfois l’impression de blockage qui marque la première page des sites ou applications web que vous visitez, mais après tout devient très fluide.

Il se peut également que les développeurs habitués au Server-Side Redering trouve le Client-Side Rendering plus contraignant, car les éléments du back-end et du front-end sont séparés et géré différemment. Or, le CSR permet de séparer les tâches ce qui facilite le développement de grandes applications scalables en impliquant de nombreux développeurs, chacun spécialisé dans un domaine particulier, autrement dit, le font-end ou le back-end.

Il existe plusieurs bibliothèques et frameworks Javascript qui permettent de monter une application Web en CSR, notamment React, Angular et Vue.js.

Server-Side Rendering vs Client-Side Rendering en vidéo