Le SSR (Server-Side Rendering) consiste à générer le HTML d'une page sur le serveur, à chaque requête, puis à l'envoyer prêt-à-afficher au navigateur. À l'inverse d'une SPA (Single Page Application) qui envoie une coquille vide JavaScript que le navigateur doit hydrater, le SSR livre du contenu indexable et affichable immédiatement. C'est le mode de rendu historique du web (PHP, Rails, Django) — réintroduit côté React via Next.js, Remix ou Nuxt côté Vue.
Le SSR a deux gros avantages. Le SEO : Google lit le HTML directement, sans dépendre de l'exécution JavaScript (qui est aléatoire côté Googlebot). Le premier paint : l'utilisateur voit du contenu en ~500 ms-1 s, là où une SPA reste blanche jusqu'à hydratation complète — c'est ce qui plombait les Core Web Vitals des SPA. Le défaut : chaque requête coûte du CPU serveur, donc ça scale moins bien qu'un SSG servi par CDN.
Quand choisir SSR plutôt que SSG ou ISR ? Quand le contenu est personnalisé par utilisateur (dashboard, espace client, prix B2B), quand les données changent à chaque requête (cours de bourse, stock e-commerce temps réel), ou quand vous avez un volume de pages tellement énorme que le SSG devient ingérable. Pour la majorité des sites marketing, l'ISR ou le SSG sont préférables. Avec Next.js App Router, on mixe les trois modes page par page selon le besoin. Voir nos sites sur-mesure pour des cas concrets.
SSR vs SSG vs ISR : quel mode pour quel contenu
- [SSG](/glossaire/ssg/) : pages statiques générées au build (blog, vitrine, marketing) — performance max, coût minimal.
- [ISR](/glossaire/isr/) : SSG + revalidation périodique (e-commerce catalogue, news) — frais sans rebuild complet.
- SSR : rendu à chaque requête (espace utilisateur, données ultra-fraîches, A/B test serveur) — flexibilité max, coût CPU.
- Client-side (SPA) : à éviter pour les pages indexables — réservé aux apps connectées (dashboards post-login).
