RSE, SSR, SSG, ISR: comment choisir le bon paradigme de rendu

Les frameworks Web modernes offrent de nombreuses options sur la façon de fournir un site ou une application du serveur au client. Vous pouvez générer du code HTML de chaque côté ou le pré-rendre pour une distribution à grande vitesse via un réseau de diffusion de contenu.

Décider comment structurer un site ou une application dépend de quelques facteurs différents. Vous devez savoir comment les visiteurs accéderont à votre site ou à votre application. Vous devez comprendre si la vitesse de chargement est plus importante lors du chargement initial ou de la navigation ultérieure. Tenez également compte de la fréquence à laquelle vous mettrez à jour le 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 connaître les avantages et les inconvénients de chacune peut vous aider à choisir celle qui convient à votre site.

RSE: le navigateur prend les choses en main

CSR signifie Rendu côté client. Lorsque vous affichez une application ou un site côté client, le serveur transmet peu ou pas de code HTML, à l'exception d'un petit morceau de code passe-partout. 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 s'affiche côté client, le serveur transmet un script au client qui générera le code HTML sur le navigateur du client. Cela permet aux applications d'une seule page de ne pas rafraîchir le navigateur lorsque vous interagissez avec elles.

Les applications CSR sont souvent rapides à charger lors de la navigation, mais elles peuvent être lentes à charger initialement. 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 frameworks JavaScript modernes populaires inclure une option pour la RSE.

Les pages et les applications rendues entièrement 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 navigue vers le même point de départ.

SSR: rendu sur un serveur central

SSR signifie Rendu côté serveur. Il s'agit d'une forme beaucoup plus traditionnelle de rendu de page Web dans laquelle les sites génèrent du HTML basé sur des modèles et envoient un mélange de HTML, de feuilles de style et de scripts au client. La majorité des les frameworks web backend les plus populaires entrent dans cette catégorie.

Les applications et les sites rendus côté serveur ont tendance à avoir des chargements initiaux plus rapides, mais chaque navigation successive nécessitera une actualisation complète. Cela signifie que non seulement cela prendra plus de temps, mais que les développeurs travaillant avec SSR devront prendre en compte la gestion des sessions.

Le plus gros avantage des sites et applications générés par SSR est la cohérence de la navigation par chemin. Un utilisateur saisissant un chemin donné sera directement dirigé vers la page demandée. Certains frameworks gèrent les redirections d'utilisateurs de page en page dans 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 une page rendue par le serveur au client. Une fois la page chargée, un événement connu sous le nom d'hydratation se produit dans lequel des événements de script côté client sont attachés aux contrôles de la page. À partir de maintenant, le client gère toute navigation.

Une dynamique mixte offre aux utilisateurs la possibilité d'accéder directement à n'importe quelle page d'une application, tout en bénéficiant de la rapidité et de la fluidité d'une application d'une seule page. Next.js offre plusieurs paradigmes de rendu, tout comme Nuxt.js et Sveltekit.

SSG: rendu réduit

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

Il s'agit d'une méthode extrêmement efficace pour servir des pages Web extrêmement rapidement. Les résultats sont normalement compilés dans des ensembles simples contenant tout le code HTML et les feuilles de style nécessaires pour une page individuelle. Ces lots sont aussi compacts que possible pour garantir que l'utilisateur les recevra le plus rapidement possible.

Les sites SSG ont tendance à offrir des vitesses de chargement exceptionnellement rapides, malgré la nécessité d'un rafraîchissement pour chaque navigation. Cependant, le principal inconvénient d'un site statique est son manque de flexibilité. Les systèmes hautement dynamiques tels que les applications de médias sociaux ou les plates-formes de commerce électronique complexes nécessiteront bien plus de changements qu'un SSG ne peut facilement gérer.

De nombreux sites statiques nécessiteront également une plus grande quantité de temps système pour être modifiés, car chaque nouvelle modification devra être compilée de manière indépendante. Cela fait du rendu de style SSG un mauvais choix pour les sites qui changent rapidement, comme une vitrine numérique avec un inventaire en évolution rapide ou des applications de médias sociaux.

ISR: un peu de tout

De loin le type de rendu le plus complexe, mais aussi le plus avantageux, ISR signifie Incremental Static Regeneration. ISR allie la vitesse et l'évolutivité des sites générés statiquement à la réactivité des applications de style SSR et CSR.

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

Si une version en cache de la page n'existe pas, ou si suffisamment de temps s'est écoulé depuis sa génération, le serveur générera une nouvelle version. Cette nouvelle version sera transmise au client et mise en cache pour une utilisation future.

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

Plusieurs frameworks modernes offrent déjà l'option d'un rendu de style ISR. Beaucoup d'autres ont un support pour la génération incrémentielle dans le développement. La plupart des principaux frameworks prendront bientôt en charge le rendu ISR s'ils ne le font pas déjà.

Quel type de rendu est le meilleur?

Il existe plusieurs façons de rendre un site Web ou une application. Chacun de ces quatre types de rendu a de multiples variations. 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 sur votre site ou votre application.

Lors du choix d'un paradigme de rendu pour votre projet, il est important de prendre en compte la vitesse, la manière dont votre public utilisera votre projet et la fréquence à laquelle le site changera. Ce seront les principes fondamentaux qui vous aideront à décider de la meilleure façon de structurer votre site ou votre application.