Les frameworks web modernes offrent de nombreuses options pour la diffusion d’un site ou d’une application entre le serveur et le client. Vous pouvez générer du HTML d’un côté ou de l’autre, ou effectuer un pré-rendu pour une distribution à grande vitesse via 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 lors 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 la bonne méthode pour votre site.
RSE : Le navigateur prend les choses en main
CSR signifie Client Side Rendering (rendu côté client). Lorsque vous effectuez le 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épend 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 comprennent 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 navigue 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écessite un rafraîchissement complet. Cela signifie non seulement qu’ils prendront plus de temps, mais aussi que les développeurs travaillant avec le SSR 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à, le client se charge 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é du client ou du 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 réseau de distribution de contenu (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 afin que l’utilisateur les reçoive le plus rapidement possible.
Les sites SSG tendent à offrir des vitesses de chargement exceptionnellement rapides, bien qu’ils nécessitent une actualisation 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 indépendamment. 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, l’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 en cache non expirée de la page. 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à l’option 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 frameworks majeurs supporteront bientôt le rendu ISR s’ils ne le font pas déjà.
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.
