SSR vs CSR : définitions, différences et place du SSG

Rendering : ce qui se passe avant que la page s'affiche

Le rendering désigne l'étape où du code devient une page lisible (textes, images, boutons). Trois endroits peuvent l'accueillir. Sur le serveur, au moment de la visite. Dans le navigateur du visiteur. Ou bien des heures plus tôt, lors de la mise en ligne.

Tout se décide sur le HTML initial, autrement dit la toute première réponse reçue par le navigateur. Le texte de la page y figure déjà ? Alors visiteur et Google le voient sur-le-champ. Si ce HTML arrive presque vide, il faut patienter le temps que JavaScript le remplisse. Un détail technique, en apparence seulement : il pèse sur votre référencement naturel autant que sur vos Core Web Vitals.

Vous dirigez une entreprise ? Ce sujet n'a rien de théorique pour vous. Il touche la vitesse que ressentent vos prospects, votre visibilité dans les résultats de recherche et, au bout du compte, ce que vous payez pour héberger le site.

SSR : le server side rendering, une page fabriquée côté serveur

En server side rendering, chaque demande déclenche l'assemblage complet de la page par le serveur. Celui-ci récupère les données, les insère dans le modèle, puis expédie un HTML prêt à lire. Reste au navigateur à l'afficher. Un peu de JavaScript arrive ensuite pour rendre l'ensemble interactif.

Comment fonctionne le rendu côté serveur

Prenons un clic sur un lien. La demande part vers le serveur, qui interroge au besoin la base de données et génère la page à la volée. Résultat : un contenu toujours à jour. Voilà pourquoi le SSR brille sur les pages dynamiques, celles qui changent souvent ou dépendent de la personne connectée.

Atouts et limites du SSR

• Texte présent directement dans le HTML, ce que les robots de Google adorent
• Affichage rapide dès le départ, même sur un téléphone d'entrée de gamme
• Informations fraîches en permanence : stock, prix, disponibilités
• Charge serveur plus lourde, puisque chaque visite lance un calcul
• Hébergement et maintenance plus exigeants qu'avec un site statique

CSR : le rendu côté client piloté par JavaScript

Changement de logique avec le client side rendering. Le serveur n'envoie qu'une page quasi vide, accompagnée d'un volumineux fichier JavaScript (le bundle). Au navigateur d'exécuter ce code pour construire l'affichage. On parle alors de single page application : une page unique se charge, puis tout se met à jour sans rechargement complet.

Une logique d'application plutôt que de site

React, Angular, Vue : c'est avec ces bibliothèques que le modèle s'est imposé. Passé le premier chargement, on navigue avec une fluidité proche d'un logiciel installé. Chaque clic répond vite, seules les données changeant. Et le serveur ? Il se contente bien souvent de fournir une API.

Atouts et limites du CSR

• Navigation très fluide une fois le premier chargement terminé
• Serveur ménagé, le travail étant fait côté client
• Liberté totale pour concevoir des interfaces riches et interactives
• Premier affichage plus lent, le temps de télécharger puis d'exécuter le JavaScript
• Aucune garantie que les moteurs de recherche lisent bien le contenu

SSG : la génération statique faite à l'avance

Le static site generation va encore plus loin que le SSR. Ici, chaque page est générée une seule fois, à la mise en ligne, puis conservée sous forme de fichier HTML. Un visiteur se présente ? Le serveur ne calcule rien, il tend simplement un fichier déjà prêt.

Rien de plus facile, ensuite, que de déposer ces fichiers sur un CDN, ce réseau de serveurs installés près des visiteurs. On obtient un site rapide, robuste et bon marché à héberger. Le revers ? Modifier un texte oblige à regénérer les pages concernées.

• Pages servies en un éclair, sans aucun calcul pendant la visite
• Lecture parfaite par Google, grâce à un HTML complet
• Surface d'attaque réduite, faute de logique serveur sollicitée à chaque visite
• Contenu figé d'une publication à l'autre
• Mal adapté aux pages qui changent selon l'utilisateur

SSR vs CSR vs SSG : lequel choisir selon votre cas

Aucun mode ne gagne par défaut. Tout dépend de la mission confiée à la page. Je vous propose de partir d'une seule question : cette page doit-elle être trouvée sur Google, ou sert-elle d'abord à des utilisateurs déjà connectés ?

Vous voulez attirer des prospects depuis Google

Mon conseil : du SSG pour les pages stables (accueil, services, articles). Basculez sur le SSR dès qu'une page change souvent, à l'image d'un catalogue dont le stock évolue en temps réel. Dans les deux cas, le texte figure d'emblée dans le HTML initial, et votre indexation Google s'en trouve facilitée.

Vous construisez un outil métier ou un espace client

Là, gardez le CSR. Tableau de bord, back office, application protégée par un mot de passe : rien de tout cela n'a besoin d'être référencé. Vos utilisateurs profiteront de la fluidité d'une single page application, et votre serveur restera léger.

Vous avez les deux besoins

C'est de loin la situation la plus courante. Et c'est précisément là que Next.js et les frameworks du même genre deviennent précieux, car ils mélangent les modes page par page : statique pour le blog, rendu serveur pour le catalogue, rendu client pour l'espace membre. Quand nous menons une création de site internet, ce sont vos objectifs commerciaux qui dictent le mode de chaque page, jamais la technologie à la mode.

Questions fréquentes