CSR, SSR, SSG, ISR, WTF?

CSR, SSR, SSG, ISR, les développeurs sont friands d'abréviations, mais qu'est ce qu'il se cache derrière ces sigles ? Quels sont les avantages et les inconvénients de ces technologies ? On fait le tour 👇

CSR

Client Side Rendering. C'est la technologie la plus commune lorsqu'on fait une app React.

Le code React est executé coté client (navigateur). C'est le mode de fonctionnement de base lorsque vous commencez une app avec create-react-app

Avantages

• Le code est executé entièrement coté client. Le serveur est réduit à son stricte minimum, et vous pouvez héberger très facilement votre application sur la multitude d'offres PaaS (encore un sigle 😱) qui existent : Heroku, Vercel, Cloudflare Pages, Google App Engine, Github Pages, Netlify,...

Inconvénients

• Si vous inspectez la source de la page, vous verrez qu'elle est réduite à son stricte minimum. Un div, un script js chargé,... et c'est tout. Ce n'est pas donc pas la solution optimale si vous avez des besoins en SEO importants. Et si votre utilisateur a désactivé javascript (ca arrive il parait...) il aura une page blanche.

Quand l'utiliser ?

Si vous n'avez pas besoin de SEO. Par exemple un app accessible uniquement après une identification.

Librairies / Frameworks

Vous pouvez utiliser nativement React, avec un create-react-app, c'est le fonctionnement "de base" :)

SSR

Server Side Rendering

Les pages sont générées à la volée par le serveur puis envoyées au client

Avantages

• La page est complètement générée coté serveur, donc le serveur envoie une vrai page html complète, qui pourra être lue par les moteurs de recherche. Et donc entièrement compatible pour le SEO.

Inconvénients

• Chaque page demandée va être générée coté serveur, donc la charge serveur sera plus importante, ce qui nécessite un serveur plus conséquent.
• Si vous utulisez un CMS, à chaque requête d'une de vos pages, le serveur va interroger votre CMS pour "construire" la page. Ce qui peut ralentir votre serveur en fonction de la charge, et du temps de réponse de votre CMS.
• Si vous utilisez une politique de cache sur vos pages (ce que vous devez faire pour éviter le point au dessus) il vous faudra invalider ce cache lorsqu'une information dans le CMS a changé, pour que la page soit re-générée et re-cachée.
• Certains composants React que vous utilisez peuvent ne pas être compatibles avec le SSR, car ils reposent sur les objets window et document (qui n'existent pas coté serveur). Ce qui vous obligera à adapter votre code, pour n'en executer qu'une partie coté serveur, et le reste coté client (n'ayez crainte, ca se fait assez facilement).

Quand l'utiliser ?

Si vous avez un site ou une app qui a de forts besoins en SEO. Il vous faudra doser avec précision la politique de cache : un cache trop long vous obligera à invalider manuellement ce dernier à chaque changement dans le CMS, quand un cache trop court surchargera inutilement votre serveur de requêtes vers votre CMS.

Librairies / Frameworks

NextJS, GatsbyJS, Remix

SSG

Static Site Generation

Ici, les pages vont être générées lors du build et stockées sous forme de pages html "classiques".

Avantages

• Entièrement compatible avec le SEO
• Aucune charge serveur, les pages sont déjà générées

Inconvénients

• Toutes les pages sont générées au moment du build, donc suivant votre nombre de page à générer, le build peut être assez long.
• Si vous utilisez un CMS, c'est lors de cette phase de build que votre CMS va être interrogé, augmentant encore la durée du build
• Les pages sont générées une fois lors du build. Donc si vous changez quelque chose dans votre CMS, vous devrez à nouveau build votre projet pour que les modifications soient effectives
• Tout comme le SSR, certains composants React peuvent ne pas être compatibles.

Quand l'utiliser ?

Si vous recherchez les performances maximales, que votre site web comprend un nombre de pages "raisonnable" et qu'elles ne sont pas soumises à des changements trop fréquents.

Ce site / blog par exemple utilise du SSG. Les pages sont rédigées en MDX (Mardown étendu pour intégrer du React dedans) puis générées au moment du build.

Librairies / Frameworks

NextJS, GatsbyJS, Docusaurus

ISR

Incremental Static Regeneration

Ici, on va combiner le meilleur du SSR, et du SSG. L'ISR, c'est du SSG, mais au lieu de devoir recompiler le projet à chaques changements, on va pouvoir dire à notre serveur de regénérer uniquement une page en particulier. Donc de régénerer une page statique de façon incrémental (ISR)

Et nous avons 2 moyens de faire de l'ISR :

• Avec de la temporalité, c'est à dire par exemple de venir regénérer la page tous les X jours
• A la demande, où lorsque quelque chose est modifiée coté CMS, un call est lancé vers notre serveur lui informant de regénérer une ou plusieurs pages spécifiques.

Avantages

• Entièrement compatible avec le SEO
• Aucune charge serveur, les pages sont déjà générées
• Pour l'ISR "On-Demand", les changements coté CMS sont immédiats (mis à part le temps de rebuild de la page)

Inconvénients

• Pour l'ISR "à intervalle", vous allez avoir les mêmes problématique que la gestion du cache pour le SSR. A savoir : trop long et vos modifications ne seront pas visible, trop court et vous allez faire des requêtes inutiles vers votre CMS. La seule différence néanmoins et que le rebuild se fera de manière transparente, et non pas lors d'une "demande" de la part d'un client.
• Pour l'ISR "à la demande", vous en voyez un ? 😉

Librairies / Frameworks

NextJS Attention, le "On-Demand ISR" est toujours en phase de BETA

En bref

Choisissez-bien vos technologies !

Chaque technologie a ses avantages et ses inconvénients, choisissez en fonction de vos besoins, et de vos futurs besoins !

Si vous commencez avec du CSR car c'est plus rapide à développer, et qu'après 6 mois votre service marketing vient vous voir en disant "je comprends pas, on est nul en SEO sur l'app", vous risquez de passer un temps fou à migrer vers une solution SSR.

On-Demand ISR

Si vous avez du temps devant vous (au moins pour l'apprentissage), et voulez développer "pour le futur", l'ISR On-Demand, c'est le futur 🤗

	CSR	SSR	SSG	ISR
SEO Friendly	❌	✅	✅	✅
Charge serveur maitrisée	✅	❌	✅	✅
Performances / vitesse de chargement	❌	❌	✅	✅
Facilité de mise à jour depuis un CMS	✅	✅	❌	✅

[*] Dans ce tableau, je me base sur du SSR sans politique de cache des fichiers (ce qui n'est pas bien) et sur de l'ISR On-Demand.