Le Server-Side Rendering (SSR), c’est la technique qui permet à un serveur de générer le HTML d’une page AVANT de l’envoyer à ton navigateur. Résultat : tu vois le contenu immédiatement, sans attendre que JavaScript fasse son boulot côté client. C’est une notion que tout dev web finit par croiser, et que beaucoup de débutants évitent parce qu’elle fait peur. Dans cet article, on démystifie tout ça, simplement.
Comment fonctionne le rendu d’une page web, concrètement ?
Avant de parler de SSR, il faut comprendre les deux grandes façons de construire une page web : côté serveur ou côté client. Et pour ça, une petite métaphore s’impose.
Imagine que tu commandes une pizza. Il y a deux options :
- Option 1 : Le restaurant te livre une pizza déjà cuite, prête à manger. Tu ouvres la boîte, tu manges. Rapide.
- Option 2 : Le restaurant t’envoie les ingrédients, et c’est toi qui dois la cuisiner chez toi. Tu attends plus longtemps avant de manger.
Le SSR, c’est l’option 1. Le serveur « cuisine » la page HTML avant de te l’envoyer. Ton navigateur n’a plus qu’à afficher ce qu’il reçoit.
L’option 2, c’est ce qu’on appelle le Client-Side Rendering (CSR) : le serveur envoie un fichier HTML quasi vide, et c’est JavaScript qui reconstruit toute la page dans ton navigateur. C’est ce que font par défaut des frameworks comme React ou Vue.js quand ils sont utilisés sans configuration particulière.
Pourquoi le CSR pose un problème dans certains cas ?
Le Client-Side Rendering a un défaut majeur : pendant que JavaScript charge et s’exécute, l’utilisateur voit une page blanche ou un écran de chargement. Sur une connexion rapide, c’est quasi invisible. Mais sur mobile ou avec une mauvaise connexion, ça peut prendre plusieurs secondes.
Il y a aussi un deuxième problème, souvent sous-estimé : le SEO. Les robots de Google ont du mal à lire du contenu généré par JavaScript. Techniquement, ils peuvent le faire, mais ce n’est pas garanti. Si tu veux que ton site soit bien indexé, c’est risqué de tout miser sur le CSR.
C’est exactement pour ça que le SSR a fait son grand retour ces dernières années, notamment avec des frameworks comme Next.js ou Astro.
C’est quoi exactement le SSR, et qu’est-ce qui se passe sous le capot ?
Avec le SSR, à chaque fois qu’un utilisateur demande une page, le serveur exécute le code, récupère les données nécessaires, construit le HTML complet, puis l’envoie au navigateur. Le navigateur n’a rien à calculer : il affiche directement ce qu’il reçoit.
Voici ce qui se passe étape par étape :
- L’utilisateur tape une URL dans son navigateur.
- Le navigateur envoie une requête au serveur.
- Le serveur exécute le code (récupère les données en base, appelle une API, etc.).
- Le serveur génère un fichier HTML complet avec toutes les données déjà intégrées.
- Ce HTML est envoyé au navigateur.
- Le navigateur affiche la page. L’utilisateur voit le contenu immédiatement.
Ensuite, si tu utilises un framework moderne comme React, une étape supplémentaire s’enclenche : l’hydratation. C’est le moment où JavaScript « prend vie » sur la page déjà affichée et la rend interactive (boutons, formulaires, etc.).
SSR vs CSR vs SSG : c’est quoi la différence entre les trois ?
Il existe en réalité trois grandes stratégies de rendu, et elles ne s’utilisent pas dans les mêmes situations. Voici un tableau pour s’y retrouver facilement :
| Stratégie | Quand la page est générée ? | Idéal pour… |
|---|---|---|
| SSR | À chaque requête, côté serveur | Données dynamiques, persos, fraîches |
| CSR | Dans le navigateur, après chargement JS | Apps interactives, dashboards privés |
| SSG | Au moment du build (une seule fois) | Blogs, landing pages, sites statiques |
Le SSG (Static Site Generation) est une troisième option : la page est générée une seule fois, au moment où tu déploies ton site. Elle ne change pas jusqu’au prochain build. C’est ultra rapide à servir, mais pas adapté si tes données changent souvent.
Si tu veux aller plus loin sur la mise en page web en général, notre guide sur créer son premier site web en 2026 te donne une bonne vue d’ensemble des chemins possibles.
Quels sont les vrais avantages du SSR ?
Le SSR apporte des bénéfices concrets, surtout si ton site a besoin d’être visible sur Google ou s’adresse à des utilisateurs avec des connexions variées.
- Meilleur SEO : Les robots des moteurs de recherche reçoivent un HTML complet et indexable sans effort supplémentaire.
- Affichage plus rapide (FCP) : Le premier contenu visible arrive plus tôt, ce qui améliore l’expérience utilisateur et les métriques Core Web Vitals.
- Accès aux données en temps réel : Chaque requête peut aller chercher les données les plus fraîches (stock, prix, profil utilisateur…).
- Meilleure accessibilité : Les utilisateurs avec JavaScript désactivé voient quand même du contenu.
Et les inconvénients, ils sont où ?
Le SSR n’est pas une solution miracle, et il a des contraintes qu’il faut connaître avant de se lancer.
- Charge serveur plus importante : Le serveur travaille à chaque requête. Si ton site a beaucoup de trafic, ça peut coûter cher en ressources.
- Temps de réponse serveur (TTFB) plus long : Le navigateur doit attendre que le serveur finisse de calculer la page. Sur des pages complexes avec beaucoup de données, ça peut ajouter de la latence.
- Complexité de déploiement : Tu as besoin d’un vrai serveur (ou d’une plateforme compatible comme Vercel ou Railway). Un simple hébergement de fichiers statiques ne suffit pas.
- Hydratation à gérer : Si tu utilises un framework JS avec SSR, tu dois faire attention à ce que le HTML généré côté serveur corresponde exactement à ce que React (ou Vue) attendrait côté client. Sinon, tu obtiens des erreurs d’hydratation.
Comment activer le SSR dans un projet concret ?
En pratique, tu n’implémentes presque jamais le SSR from scratch : tu utilises un framework qui le gère pour toi. Voici deux exemples concrets :
Avec Next.js (React) :
Tu exportes une fonction getServerSideProps dans ta page. Elle s’exécute côté serveur à chaque requête et passe les données au composant.
// pages/produit.js
export async function getServerSideProps(context) {
// Cette fonction tourne sur le serveur, pas dans le navigateur
const res = await fetch('https://api.exemple.com/produit/1')
const data = await res.json()
return {
props: { produit: data } // Passé au composant en dessous
}
}
export default function Produit({ produit }) {
return <h1>{produit.nom}</h1>
}
Le HTML final envoyé au navigateur contiendra déjà le nom du produit. Pas besoin d’attendre JavaScript.
Avec Vue.js via Nuxt :
Vue.js a son propre équivalent qui s’appelle Nuxt. La logique est identique : tu déclares que tu veux du SSR, et le framework s’occupe du reste.
Le SSR, c’est fait pour quel type de projet ?
Le SSR brille sur des projets où le contenu change fréquemment, où le SEO est critique, ou où l’expérience utilisateur doit être immédiate dès le premier chargement.
Quelques exemples concrets :
- Un site e-commerce avec des prix et des stocks qui changent en temps réel
- Un blog ou un média qui veut être bien référencé sur Google
- Un tableau de bord utilisateur avec des données personnalisées (profil, historique d’achats…)
- Une appli SaaS dont les pages doivent s’afficher vite sur mobile
Si ton projet est plutôt une application interne, un dashboard d’administration ou une app qui tourne derrière une authentification, le CSR reste souvent suffisant. Comprendre comment fonctionne une API t’aidera à mieux saisir comment les données circulent dans ces différents scénarios.
En résumé : le Server-Side Rendering
Le SSR, c’est une façon de générer le HTML d’une page directement sur le serveur, avant de l’envoyer au navigateur. C’est l’opposé du CSR, où c’est JavaScript qui construit la page dans ton navigateur. Le SSR améliore le SEO, accélère l’affichage du premier contenu et permet de travailler avec des données fraîches. Mais il demande un vrai serveur et ajoute de la complexité. En pratique, des frameworks comme Next.js rendent ça accessible sans avoir besoin de tout coder soi-même.
Questions fréquentes sur le Server-Side Rendering
Le SSR est-il obligatoire pour un bon référencement Google ?
Non, ce n’est pas obligatoire, mais c’est fortement recommandé. Google peut lire du JavaScript, mais ce n’est pas toujours fiable et rapide. Avec le SSR, tu t’assures que le contenu est indexable sans effort supplémentaire de ta part.
Quelle est la différence entre SSR et SSG ?
Avec le SSR, la page est générée à chaque fois qu’un utilisateur la demande. Avec le SSG, elle est générée une seule fois lors du déploiement. Le SSR est adapté aux données dynamiques, le SSG aux contenus qui changent rarement comme un blog ou une landing page.
Est-ce que je peux mélanger SSR et CSR dans un même projet ?
Oui, et c’est même courant. Next.js par exemple te permet de choisir la stratégie page par page. Tu peux avoir une page d’accueil en SSR, une page de blog en SSG, et un dashboard en CSR, tout dans le même projet.
C’est quoi l’hydratation dont on entend souvent parler avec le SSR ?
L’hydratation, c’est l’étape où JavaScript « reprend le contrôle » d’une page déjà affichée en SSR. Le navigateur reçoit le HTML statique (généré par le serveur), l’affiche, puis React ou Vue vient s’y attacher pour rendre les éléments interactifs comme les boutons ou les formulaires.
Le SSR est-il plus lent que le CSR ?
Pas forcément. Le SSR peut avoir un TTFB (Time To First Byte) légèrement plus long, car le serveur doit calculer avant de répondre. Mais le contenu s’affiche souvent plus vite pour l’utilisateur, car le navigateur n’a pas à attendre que JavaScript charge et s’exécute.
Faut-il un hébergement spécial pour faire du SSR ?
Oui. Contrairement au SSG où tu peux héberger des fichiers statiques sur n’importe quoi, le SSR nécessite un serveur qui peut exécuter du code Node.js (ou Python, PHP…). Des plateformes comme Vercel, Render ou Railway gèrent ça facilement, souvent avec un plan gratuit pour démarrer.