CSR, SSR, SSG, ISR : Comment choisir le bon paradigme de rendu ?

Les frameworks web modernes offrent de nombreuses options sur la manière de diffuser un site ou une application du serveur au client. Vous pouvez générer du HTML de part et d’autre ou effectuer un pré-rendu pour une distribution à grande vitesse par le biais d’un réseau de diffusion de contenu.

Le choix de la structure d’un site ou d’une application dépend de plusieurs facteurs. Vous devez savoir comment les visiteurs accèderont à votre site ou à votre application. Vous devez savoir si la vitesse de chargement est plus importante lors du chargement initial ou de la navigation ultérieure. Pensez également à la fréquence des mises à jour du site.

Gardez tous ces facteurs à l’esprit pour peser le pour et le contre de chaque paradigme de rendu.

Rendre les sites web de plusieurs façons

Le rendu d’un site web fait référence au processus par lequel un site web est affiché dans un navigateur web. Il existe de nombreuses façons d’aborder le processus de conversion des données brutes en HTML formaté sur l’écran d’un utilisateur.

Chaque méthode a ses avantages et ses inconvénients, et le fait de connaître les avantages et les inconvénients de chacune d’entre elles peut vous aider à choisir celle qui convient le mieux à votre site.

RSE : Le navigateur prend les choses en main

CSR signifie Client Side Rendering (rendu côté client). Lors du rendu d’une application ou d’un site côté client, le serveur ne transmet que peu ou pas de code HTML, à l’exception d’un petit morceau de code de base. La page demande ensuite toutes les données dont elle a besoin au serveur, après l’événement de chargement de la page, via des requêtes AJAX.

Lorsqu’une application ou une page est rendue côté client, le serveur transmet au client un script qui génère le code HTML sur le navigateur du client. Cela permet de créer des applications à page unique qui n’actualisent pas le navigateur lorsque vous interagissez avec elles.

Les applications CSR sont souvent rapides à charger lors de la navigation, mais elles peuvent être lentes à charger au départ. La vitesse dépendra en grande partie du cadre que vous choisissez pour effectuer le rendu et du nombre de bibliothèques et de modules complémentaires que vous utilisez. La plupart des frameworks JavaScript modernes et populaires incluent une option pour la RSE.

Les pages et applications entièrement rendues côté client souffrent de l’impossibilité de naviguer directement vers une page donnée à l’aide d’une URL. Lorsqu’une application rendue côté client démarre pour la première fois, quelle que soit l’URL saisie, elle naviguera vers le même point de départ.

SSR : Rendu sur un serveur central

SSR signifie Server Side Rendering (rendu côté serveur). Il s’agit d’une forme beaucoup plus traditionnelle de rendu de pages web dans laquelle les sites génèrent du HTML sur la base de modèles et envoient un mélange de HTML, de feuilles de style et de scripts au client. La majorité des frameworks web backend les plus populaires appartiennent à cette catégorie.

Les applications et sites rendus côté serveur ont tendance à se charger plus rapidement au départ, mais chaque navigation successive nécessitera une actualisation complète. Cela signifie non seulement qu’ils prendront plus de temps, mais aussi que les développeurs qui travaillent avec le rendu côté serveur devront prendre en compte la gestion des sessions.

Le plus grand avantage des sites et des applications générés par la RSS est la cohérence de la navigation par chemin. Un utilisateur entrant dans un chemin donné sera conduit directement à la page demandée. Certains frameworks gèrent les redirections de l’utilisateur d’une page à l’autre au sein de l’application, mais les utilisateurs peuvent ne pas être en mesure d’accéder à la page qu’ils souhaitent initialement.

De nombreux frameworks modernes proposent des solutions mixtes qui commencent par servir au client une page rendue par le serveur. Une fois la page chargée, un événement connu sous le nom d’hydratation se produit, au cours duquel des événements de script côté client sont attachés aux contrôles de la page. À partir de là, c’est le client qui s’occupe de la navigation.

Une dynamique mixte permet aux utilisateurs d’accéder directement à n’importe quelle page d’une application, tout en bénéficiant de la vitesse et de la fluidité d’une application à page unique. Next.js propose plusieurs paradigmes de rendu, tout comme Nuxt.js et Sveltekit.

SSG : Rendu minimisé

SSG, ou Static Site Generation, évite de générer du HTML du côté client ou serveur. Au lieu de cela, les sites et applications de type SSG précompilent toutes les pages dont ils pourraient avoir besoin et transmettent les résultats à un CDN pour une diffusion rapide.

Il s’agit d’une méthode extrêmement efficace pour servir des pages web très rapidement. Les résultats sont normalement compilés dans des paquets simples contenant toutes les feuilles de style et le code HTML nécessaires pour une page individuelle. Ces paquets sont aussi compacts que possible pour que l’utilisateur les reçoive le plus rapidement possible.

Les sites SSG ont tendance à offrir des vitesses de chargement exceptionnellement rapides, bien qu’ils nécessitent un rafraîchissement pour chaque navigation. Le principal inconvénient d’un site statique est toutefois son manque de flexibilité. Les systèmes très dynamiques, tels que les applications de médias sociaux ou les plateformes de commerce électronique complexes, nécessiteront beaucoup plus de changements qu’un SSG ne peut facilement gérer.

De nombreux sites statiques nécessiteront également une plus grande quantité de frais généraux pour être modifiés, car chaque nouvelle modification devra être compilée de manière indépendante. Cela fait du rendu de type SSG un mauvais choix pour les sites qui changent rapidement, comme une vitrine numérique dont l’inventaire change rapidement ou des applications de médias sociaux.

ISR : un peu de tout

Facilement le type de rendu le plus complexe, mais aussi le plus bénéfique, ISR signifie Incremental Static Regeneration (régénération statique incrémentale). L’ISR allie la vitesse et l’évolutivité des sites générés de manière statique à la réactivité des applications de type SSR et CSR.

Lorsqu’une page est demandée dans une page ou une application de type ISR, le serveur vérifie d’abord s’il existe une version non expirée de la page dans la mémoire cache. Si c’est le cas, le serveur servira immédiatement la page mise en cache.

S’il n’existe pas de version mise en cache de la page ou si suffisamment de temps s’est écoulé depuis sa création, le serveur génère une nouvelle version. Cette nouvelle version sera transmise au client et mise en cache pour une utilisation ultérieure.

Ce type de rendu est plus complexe à mettre en place, mais il automatise la plupart des problèmes que les sites SSG rencontrent normalement. Cela permet aux applications d’offrir à la fois la vitesse et la fiabilité d’une application générée de manière statique tout en automatisant les frais généraux supplémentaires.

Plusieurs frameworks modernes offrent déjà la possibilité d’un rendu de type ISR. Beaucoup d’autres prennent en charge la génération incrémentale en cours de développement. La plupart des principaux frameworks prendront bientôt en charge le rendu ISR, si ce n’est pas déjà le cas.

Quel est le meilleur type de rendu ?

Il existe plusieurs façons d’effectuer le rendu d’un site web ou d’une application. Chacun de ces quatre types de rendu a de multiples variantes. Aucun type de rendu n’est idéal pour tous les projets, et le type que vous choisirez dépendra de ce qui est le plus important dans votre site ou votre application.

Lorsque vous choisissez un paradigme de rendu pour votre projet, il est important de tenir compte de la vitesse, de la façon dont votre public utilisera votre projet et de la fréquence à laquelle le site changera. Ce sont les principes fondamentaux qui vous aideront à décider de la meilleure façon de structurer votre site ou votre application.

S’abonner à notre newsletter