SSR vs SSG (Rendu serveur ou statique)
Le SSR (Server-Side Rendering, rendu côté serveur) et le SSG (Static Site Generation, génération statique) sont deux façons de produire les pages d'un site web. Le SSG fabrique les pages une fois, à l'avance, et les sert telles quelles — ultra-rapide. Le SSR les fabrique à chaque visite, sur le serveur — idéal quand le contenu change selon l'utilisateur ou l'instant.
Qu'est-ce que le SSG ?
La génération statique consiste à construire toutes les pages d'un site au moment du déploiement, une fois pour toutes, sous forme de fichiers prêts à l'emploi. Quand un visiteur arrive, le serveur n'a rien à calculer : il renvoie immédiatement la page déjà fabriquée. Résultat : une rapidité maximale, un coût d'hébergement faible et une grande robustesse — il n'y a presque rien qui puisse échouer au moment de la visite. Le SSG est parfait pour les contenus qui ne changent pas d'un visiteur à l'autre : une page de glossaire, un article, une landing page, une fiche produit. La contrepartie : à chaque modification du contenu, il faut régénérer les pages concernées. Pour du contenu stable ou peu fréquemment mis à jour, c'est un compromis excellent.
Qu'est-ce que le SSR ?
Le rendu côté serveur fabrique la page à la demande, au moment où le visiteur la réclame. Le serveur exécute le code, récupère les données fraîches, assemble la page et la renvoie. C'est indispensable quand le contenu dépend de qui regarde ou de l'instant : un tableau de bord personnalisé, un panier d'achat, des données qui changent en temps réel. Le SSR garantit que chacun voit une version à jour et adaptée, sans attendre une régénération globale. La contrepartie : le serveur travaille à chaque visite, ce qui demande plus de ressources et peut être un peu plus lent que de servir un fichier déjà prêt. Bien optimisé (avec du cache notamment), le SSR reste rapide, mais il a un coût que le SSG n'a pas.
SSR ou SSG : lequel choisir ?
La vraie réponse, en 2026, est : rarement l'un ou l'autre de façon exclusive. Les frameworks modernes comme Next.js permettent de choisir page par page la stratégie la plus adaptée — c'est l'approche que nous privilégions. On génère en statique (SSG) tout ce qui est stable et public : pages marketing, glossaire, articles, fiches — pour une vitesse et un SEO maximaux. On réserve le rendu serveur (SSR) aux pages réellement dynamiques ou personnalisées : espace connecté, données temps réel. Cette combinaison donne le meilleur des deux mondes : des pages publiques instantanées qui ravissent Google et les visiteurs, et un rendu à jour là où c'est nécessaire. Le bon réflexe n'est pas « SSR ou SSG ? » mais « quelle stratégie pour quelle page ? ».
Quel impact sur le SEO et la performance ?
Les deux approches servent au moteur de recherche un vrai contenu HTML dès la première réponse — c'est leur grand avantage commun sur les applications qui ne s'affichent qu'après l'exécution de beaucoup de code côté navigateur. Pour le SEO, ce contenu immédiatement lisible est précieux : il est bien indexé, et il est aussi mieux capté par les moteurs IA, qui n'exécutent pas toujours le code des pages. Côté performance, le SSG a l'avantage de la vitesse pure (rien à calculer), ce qui aide les Core Web Vitals — ces signaux de rapidité que Google prend en compte. Le SSR, bien optimisé, reste très correct, mais demande plus de soin. Pour un site vitrine ou un contenu SEO, le SSG est presque toujours le meilleur point de départ ; le SSR vient compléter là où le dynamique l'exige.
Et le rendu côté client (CSR) ?
À côté du SSR et du SSG existe une troisième approche : le rendu côté client, ou CSR. Ici, le serveur envoie une page presque vide, et c'est le navigateur qui, en exécutant du code, construit l'interface une fois chargé. C'est l'approche des applications très interactives — un tableau de bord riche, un éditeur — où l'essentiel se passe après le chargement initial. Son revers est connu : tant que le code ne s'est pas exécuté, il n'y a quasiment rien à voir ni à indexer. Or les moteurs de recherche, et plus encore les moteurs IA, n'exécutent pas toujours ce code : une page en pur CSR risque d'apparaître vide à leurs yeux, ce qui pénalise le référencement. La parade moderne consiste à rendre d'abord la page côté serveur (SSR ou SSG) pour un contenu immédiatement lisible, puis à laisser le navigateur la « réveiller » pour l'interactivité — c'est l'hydratation. On obtient le meilleur des deux : un contenu visible tout de suite, et une application vivante ensuite.
| SSG (statique) | SSR (serveur) | |
|---|---|---|
| Page fabriquée | À l'avance, une fois | À chaque visite |
| Vitesse | Maximale | Bonne (si optimisée) |
| Idéal pour | Contenu stable, public | Contenu personnalisé, temps réel |
| Exemples | Glossaire, article, landing | Tableau de bord, panier |
Les questions fréquentes
Un projet en tête ?
Décrivez-nous votre projet en deux minutes. Réponse sous 24h ouvrées, avec une première lecture concrète.