Les différentes types de rendu : Server-Side Rendering (SSR) et Client-Side Rendering (CSR)

Il existe deux principales manières de rendre une page web : côté serveur (SSR) et côté client (CSR). Chacune a ses avantages et ses inconvénients, et le choix entre les deux dépend des besoins spécifiques du projet.

Qu'est-ce que le Server-Side Rendering (SSR) ?

Avec le SSR, le navigateur envoie une requête au serveur, qui renvoie alors l'intégralité du code HTML de la page. Ce rendu peut être dynamique, avec des langages back-end tels que PHP, Python ou Java, ou statique, avec des pages HTML pré-générées.

Une fois que le navigateur reçoit la page HTML, il la traite, charge les ressources bloquantes (comme les fichiers CSS), puis affiche la page à l'écran. Ensuite, si nécessaire, le navigateur charge les ressources non bloquantes, telles que les scripts JavaScript et les images.

Avantages du SSR

Chargement initial rapide : La page est directement visible après réception du HTML.
Bon référencement (SEO) : Les moteurs de recherche peuvent facilement analyser toute la structure HTML dès la première requête.
Flexibilité technologique : Vous pouvez choisir le langage de back-end qui convient à votre projet, sans dépendre d'une technologie unique.

Inconvénients du SSR

Navigation successive plus lente : Chaque fois qu'un utilisateur change de page, le navigateur doit recharger l'intégralité du code HTML, même pour des éléments qui ne changent pas.
Absence de persistance des éléments : Si une page contient un élément comme un flux vidéo en cours, celui-ci sera interrompu lors du changement de page.
Charge accrue sur le serveur : Le serveur doit générer et envoyer le contenu HTML pour chaque requête, ce qui peut augmenter la charge.

Qu'est-ce que le Client-Side Rendering (CSR) ?

Le Client Side Rendering (CSR), ou rendu côté client, est une méthode où la génération du contenu HTML d'une page se fait directement dans le navigateur de l'utilisateur, après le chargement initial. Lorsqu'un utilisateur accède à un site qui utilise le CSR, le navigateur effectue une requête vers le serveur, mais au lieu de recevoir une page HTML complète, il obtient une structure HTML minimale avec un fichier JavaScript qui se chargera de remplir dynamiquement le contenu.

Le processus fonctionne ainsi :

Le serveur envoie une page HTML basique avec un <head> contenant les liens vers les fichiers CSS et JavaScript, et un <body> essentiellement vide.
Ensuite, le navigateur télécharge et exécute le JavaScript, qui récupère les données nécessaires (par exemple via des appels API) et génère dynamiquement le contenu de la page.
Une fois le JavaScript exécuté, la page devient interactive et complète.

Avantages du CSR

Navigation plus fluide : Une fois la page initiale chargée, les interactions suivantes sont plus rapides. Lorsqu'un utilisateur navigue entre les pages, seules les parties de la page qui changent sont mises à jour, sans avoir à recharger entièrement le HTML. Cela offre une expérience plus fluide.
Séparation front-end/back-end : Le CSR favorise une architecture où le front-end (interface utilisateur) est totalement séparé du back-end (logique métier). Cela permet aux équipes front-end de se concentrer sur l’expérience utilisateur, tandis que les API gèrent la logique et les données. Cette flexibilité peut faciliter l'évolution de l'application.

Inconvénients du CSR

Temps de chargement initial lent : Pour afficher les informations d'une page web, il est nécessaire de charger le JavaScript, qui doit ensuite être interprété par le navigateur. Ce processus peut allonger le temps nécessaire pour que l'utilisateur voie le contenu initial de la page.
Difficultés en matière de référencement : Les moteurs de recherche peuvent rencontrer des problèmes pour indexer correctement les pages, car au moment du chargement initial, le document HTML renvoyé est souvent vide, ne contenant qu'une balise <body> vide. Cela complique l'analyse de la structure du contenu par les robots d'indexation.
Dépendance technologique : Le CSR repose exclusivement sur le JavaScript pour le rendu des pages. Cela signifie qu'il n'existe pas d'alternatives en matière de langages côté client, ce qui peut poser des limites en termes de technologies utilisées.

Quel rendu choisir entre le SSR et le CSR ?

Le choix entre le Server Side Rendering (SSR) et le Client Side Rendering (CSR) dépend de plusieurs facteurs liés aux besoins spécifiques de votre projet.

Server Side Rendering (SSR) :

Le SSR est particulièrement adapté pour les sites où le référencement est crucial, comme les sites e-commerce ou les blogs. Ces types de sites bénéficient d'un chargement rapide des pages et d'une structure HTML complète, ce qui facilite l’indexation par les moteurs de recherche. Il est également adapté pour des sites où les utilisateurs recherchent principalement des informations spécifiques, comme les articles sur Wikipédia ou les questions sur Stack Overflow.

Client Side Rendering (CSR) :

Le CSR est plus approprié pour les applications nécessitant des interactions dynamiques, telles que les réseaux sociaux comme Instagram ou les plateformes de streaming comme Twitch. Sur ces sites, l'utilisateur peut discuter en temps réel dans un chat tout en regardant une vidéo, et avoir la possibilité d'interagir avec le contenu (s'abonner, aimer, commenter, etc.). Cela est également pertinent pour les back-offices, où le référencement n'est pas essentiel, mais où les utilisateurs ont besoin d'accéder à des tableaux de bord dynamiques, de modifier des données en temps réel et d'effectuer des actions sans interruption.

Approche hybride :

Il est possible de combiner SSR et CSR au sein d’un même site. Par exemple, un site e-commerce peut utiliser le SSR pour optimiser le référencement tout en intégrant des fonctionnalités interactives, comme une messagerie en temps réel, gérées par CSR. Cette approche permet d’optimiser à la fois l’expérience utilisateur et les performances SEO.

Aucune page ou chapitre n'a été ajouté à cet article.