SSG, SSR, ISR : quel mode de rendu choisir pour votre site Next.js ?

Quand on parle de Next.js à un client, la question du "mode de rendu" arrive inévitablement. SSG, SSR, ISR — trois acronymes qui semblent techniques, mais qui ont un impact direct et concret sur la vitesse de votre site, son référencement Google et vos coûts d'hébergement. Voici comment on les explique, et surtout comment on décide chez Webomax.

Le constat — Un même framework, trois philosophies#

Avant Next.js, le web fonctionnait selon deux grands modèles. D'un côté, les sites statiques : le HTML est généré une fois, déposé sur un serveur, et servi à tous les visiteurs identiquement. De l'autre, les applications dynamiques : le serveur génère la page à chaque requête, en temps réel, en fonction de l'utilisateur ou du contexte.

Ces deux approches ont chacune leurs limites évidentes :

• Le statique pur est ultra-rapide et économique, mais il ne peut pas afficher du contenu personnalisé ou mis à jour en temps réel. Chaque modification nécessite un rebuild complet du site.
• Le dynamique pur (serveur) est flexible, mais chaque requête coûte du temps CPU. Sur un site à fort trafic, les temps de réponse se dégradent et les coûts d'infrastructure montent.

Next.js a résolu ce dilemme en proposant trois stratégies de rendu qui peuvent coexister dans un même projet. Vous pouvez avoir une page d'accueil en SSG, une page de compte utilisateur en SSR, et une page de blog en ISR — tout ça dans la même application.

La solution — Comprendre les trois modes#

SSG — Static Site Generation

Le HTML est généré une seule fois au moment du build, avant que le site soit mis en ligne. Chaque visiteur reçoit le même fichier HTML pré-calculé, servi directement depuis un CDN.

Avantages : temps de chargement extrêmement faible (souvent sous 50ms), score Core Web Vitals excellent, zéro charge serveur à chaque requête. C'est le mode idéal pour les pages dont le contenu ne change pas souvent : pages de présentation, pages de services, articles de blog, landing pages.

Limitation : si le contenu change, il faut rebuilder le site. Pour un blog de 500 articles, ça prend quelques minutes — acceptable. Pour une boutique de 10 000 produits avec des prix qui changent en temps réel, c'est impossible.

SSR — Server-Side Rendering

Le HTML est généré à chaque requête, côté serveur, juste avant d'être envoyé au navigateur. Le visiteur reçoit toujours la version la plus à jour du contenu.

Avantages : contenu toujours frais, possibilité d'adapter la page à l'utilisateur (authentification, géolocalisation, préférences). Indispensable pour les dashboards, les pages de compte, les résultats de recherche filtrés.

Limitation : chaque requête consomme des ressources serveur. Le Time to First Byte (TTFB) est plus élevé qu'en SSG. Sur un site très visité, ça se traduit par des coûts d'infrastructure supérieurs.

ISR — Incremental Static Regeneration

C'est la stratégie hybride qui a rendu Next.js incontournable. Les pages sont générées statiquement au build, mais elles se régénèrent automatiquement en arrière-plan selon une fréquence définie — toutes les 60 secondes, toutes les heures, toutes les 24 heures selon vos besoins.

Le premier visiteur après l'expiration du cache reçoit la version précédente pendant que la nouvelle est générée. Le visiteur suivant reçoit la version fraîche. C'est ce qu'on appelle le modèle "stale-while-revalidate".

Avantages : la rapidité du statique avec la fraîcheur du dynamique. Parfait pour les pages produits e-commerce, les articles de blog avec commentaires, les pages tarifaires, les portfolios de réalisations.

Note : Avec Next.js 14 et les React Server Components, la logique de rendu a encore évolué. Le rendu se fait désormais composant par composant, pas seulement page par page — ce qui affine encore la granularité du contrôle.

Notre approche chez Webomax#

Avant de choisir un mode de rendu, on pose systématiquement trois questions :

• À quelle fréquence ce contenu change-t-il ? Un article de blog publié une fois par semaine n'a pas besoin de SSR. Une page de stock en temps réel, si.
• Le contenu dépend-il de l'utilisateur connecté ? Si oui, le SSR (ou une combinaison SSG + fetch côté client) est nécessaire.
• Quel est le volume de trafic attendu ? Un site institutionnel à 500 visites/mois peut se permettre du SSR sans problème. Un site à 50 000 visites/jour gagnera à maximiser le statique pour réduire les coûts et améliorer la résilience.

En pratique, voici comment on structure la majorité de nos projets :

• Pages institutionnelles (accueil, à propos, services) → SSG
• Blog, réalisations, pages de contenu éditorial → ISR avec revalidation toutes les heures
• Espaces connectés, tableaux de bord, résultats de recherche → SSR ou Client-side fetching
• Pages critiques pour le SEO avec contenu semi-dynamique → ISR avec revalidation courte

Cette approche nous permet d'atteindre systématiquement des scores Lighthouse élevés tout en garantissant la fraîcheur des données. Si vous voulez en savoir plus sur notre processus d'optimisation, lisez notre article sur comment atteindre 100/100 Lighthouse.

Ce qu'il faut retenir#

Le choix du mode de rendu n'est pas une décision purement technique — c'est une décision business. Elle impacte directement :

• Le SEO : Google indexe mieux les pages dont le contenu est présent dans le HTML initial. Le SSG et l'ISR sont avantageux sur ce point.
• La performance perçue : un TTFB bas améliore l'expérience utilisateur, réduit le taux de rebond et peut influencer le classement Google.
• Les coûts d'hébergement : maximiser le statique réduit la consommation serveur. Pour un site à fort trafic, l'économie peut être significative sur un an.
• La maintenabilité : un projet bien structuré où chaque page utilise le bon mode de rendu est plus simple à faire évoluer.

Si votre site actuel est construit sur un CMS traditionnel qui génère du HTML côté serveur à chaque requête sans cache, il y a de fortes chances que vous laissiez de la performance sur la table. Un audit de site web peut révéler exactement où se situent les goulots d'étranglement et comment les résoudre avec les bons outils.

Next.js ne fait pas de magie — mais il donne les bons outils à qui sait les utiliser.