SSG vs. SSR vs. ISR : concevoir une architecture pour les contenus dynamiques à fort trafic

Lorsqu’un site web attire des millions de visiteurs, le choix de la stratégie de rendu devient une décision d’infrastructure, et non plus simplement une préférence front-end. La génération statique de sites (SSG), le rendu côté serveur (SSR) et la régénération statique incrémentielle (ISR) proposent chacun une réponse différente au même défi : comment fournir un contenu rapide, facilement indexable et fréquemment mis à jour sans surcharger le serveur d’origine.

Cette décision est particulièrement importante pour les éditeurs de contenu, les marketplaces, les plateformes de voyage et les grands sites e-commerce. Ces entreprises doivent trouver un équilibre entre rapidité et fraîcheur des données, coûts prévisibles et personnalisation, portée mondiale et simplicité opérationnelle.

Le débat autour du rendu

Au cœur du débat se trouve une question fondamentale : quand le HTML d’une page doit-il être généré ? Avec la Static Site Generation (SSG), les pages sont générées avant que les utilisateurs ne les demandent, généralement lors d’un processus de build ou de déploiement. Le HTML ainsi produit peut ensuite être distribué via un réseau de diffusion de contenu (CDN). Le Server-Side Rendering (SSR) génère le HTML en réponse à chaque requête. Le serveur récupère les données les plus récentes, assemble la page et l’envoie au visiteur.

L’Incremental Static Regeneration (ISR) se situe entre les deux. Les pages sont générées de manière statique, mais le système peut les actualiser après une période définie ou en réponse à un événement, comme une mise à jour provenant d’un système de gestion de contenu (CMS).

Cette distinction a des conséquences directes sur les performances. Les recommandations de la plateforme web de Google expliquent que le rendu statique permet d’obtenir un Time to First Byte (TTFB) de manière constante, puisque la page n’a pas besoin d’être générée dynamiquement au moment de la requête. Le HTML pré-généré peut également être distribué via plusieurs CDN et être servi depuis des emplacements proches des utilisateurs. « De manière générale, nous encourageons les développeurs à envisager le rendu côté serveur ou le rendu statique plutôt qu’une approche reposant entièrement sur la réhydratation. » Addy Osmani et Jason Miller, équipe Google Chrome.

Cette recommandation ne signifie pas qu’il faut abandonner les applications dynamiques. Elle suggère plutôt d’éviter de rendre chaque page dépendante de JavaScript côté client ou de calculs effectués à chaque requête lorsque le contenu ne l’exige pas.

SSG : l’absorbeur de trafic

La SSG est la stratégie la plus simple pour les contenus qui changent relativement peu. La documentation, les articles éditoriaux, les pages marketing, les guides de destination et les pages pérennes sont des candidats naturels.

Une fois générée, une page statique peut être mise en cache à la périphérie du réseau et être servie sans solliciter les serveurs applicatifs ni interroger une base de données. Une soudaine augmentation du trafic, par exemple provoquée par une publication sur les réseaux sociaux ou par une actualité importante, exerce donc beaucoup moins de pression sur l’infrastructure d’origine.

Cela rend la SSG particulièrement intéressante pour les sites à fort trafic. Elle est généralement rapide, résiliente et relativement peu coûteuse à exploiter. Elle offre également une bonne visibilité dans les moteurs de recherche, puisque la réponse initiale contient déjà le contenu et les métadonnées de la page.

Sa faiblesse est la fraîcheur du contenu. Si un titre change, si un produit est retiré du catalogue ou si une promotion commence, le site peut nécessiter un nouveau build et un nouveau déploiement avant que la modification ne soit visible. Pour un petit site, ce processus reste gérable. Pour une plateforme comportant des centaines de milliers, voire des millions de routes, reconstruire l’ensemble du site peut devenir lent et coûteux.

Il existe une autre limite : la SSG suppose que l’équipe connaît, ou peut anticiper, les pages qui doivent exister. Les recommandations de Google sur web.dev soulignent que générer un fichier HTML individuel pour chaque URL possible peut devenir difficile, voire irréalisable, lorsqu’un site possède un très grand nombre de pages uniques.

Pour cette raison, la SSG doit être considérée comme une base, plutôt que comme une solution universelle. Elle fonctionne extrêmement bien pour les pages stables, mais devient moins adaptée lorsque le contenu évolue constamment ou que les URL sont créées à la demande.

SSR : la fraîcheur a un prix

Le SSR est conçu pour les pages dont le contenu doit être calculé au moment de la requête. Un espace personnel, une page affichant des stocks en temps réel, une interface de résultats de recherche ou un processus de paiement peuvent nécessiter des données qui ne peuvent pas être partagées de manière sûre via un cache public. Le principal avantage est la fraîcheur. Chaque requête peut refléter l’état le plus récent de la base de données, l’identité de l’utilisateur, ses autorisations, sa localisation ou encore les règles tarifaires. Le SSR peut également améliorer l’expérience initiale pour les pages qui devraient autrement récupérer les données dans le navigateur avant d’afficher un contenu significatif.

Mais cette flexibilité a un coût. Chaque requête peut nécessiter du calcul côté serveur, un accès à la base de données, des appels à des API et le rendu du HTML. À très grande échelle, ces opérations peuvent créer des goulots d’étranglement, notamment lorsque de nombreux utilisateurs demandent simultanément la même ressource.

La mise en cache peut réduire cette charge, mais elle modifie l’architecture. Les équipes doivent déterminer ce qui peut être mis en cache, pendant combien de temps et si la réponse d’un visiteur pourrait accidentellement être servie à un autre. La personnalisation, les cookies et les en-têtes d’autorisation peuvent tous compliquer le comportement du cache. « Le rendu côté serveur n’est pas la meilleure solution pour tout, car sa nature dynamique peut entraîner des coûts importants en ressources de calcul. » Philippe Heilman, CEO d’une société de développement logiciel.

Les techniques modernes telles que le SSR avec streaming permettent d’envoyer la première partie d’un document avant que le rendu complet de la page ne soit terminé. Cela peut améliorer la vitesse perçue, mais n’élimine pas le besoin de calcul. Le serveur doit toujours traiter les requêtes, tandis que la base de données et les API en aval doivent toujours absorber le trafic.

Le SSR devrait donc être réservé aux contenus qui nécessitent réellement une logique exécutée à chaque requête. L’utiliser par défaut pour toutes les pages peut transformer un site à fort trafic en une vaste collection de calculs répétés.

ISR : le compromis pratique

L’ISR est particulièrement utile pour les sites dont le contenu évolue régulièrement, mais pas à chaque seconde. Un catalogue de produits, un article d’actualité, une page événementielle ou une page de catégorie peuvent nécessiter des mises à jour toutes les quelques minutes, sans pour autant nécessiter une nouvelle requête vers la base de données pour chaque visiteur.

Dans un modèle ISR, la première version d’une page est générée à l’avance ou lors de la première requête. Les visiteurs reçoivent ensuite la version mise en cache tandis que le système génère en arrière-plan une version plus récente après un intervalle défini ou à la suite d’un déclencheur à la demande.

Next.js décrit cette approche comme une génération statique pouvant fonctionner page par page, sans avoir à reconstruire l’intégralité du site.« L’Incremental Static Regeneration (ISR) permet d’utiliser la génération statique page par page, sans avoir à reconstruire l’ensemble du site. », Mohamed Barba, lead software developer.

Cette approche est généralement connue sous le nom de stale-while-revalidate. Un visiteur peut brièvement recevoir l’ancienne version pendant que la nouvelle page est générée. Une fois la régénération terminée avec succès, les visiteurs suivants reçoivent la nouvelle version. Si la régénération échoue, l’ancienne version valide peut rester disponible au lieu d’exposer une erreur à tous les utilisateurs.

Vercel, qui a contribué à populariser l’ISR avec Next.js, présente cette stratégie comme une combinaison de la rapidité du contenu statique et de la flexibilité du rendu côté serveur. Sa documentation recommande notamment l’ISR pour les catalogues e-commerce, les sites média et les plateformes dont les mises à jour interviennent selon un rythme de quelques minutes ou quelques heures plutôt qu’en temps réel.« L’ISR est une stratégie de mise en cache qui combine la rapidité du contenu statique avec la flexibilité du rendu côté serveur. », David Wilson, CEO d’une société de développement logiciel.

Le compromis réside dans la staleness contrôlée, c’est-à-dire la possibilité que le contenu soit temporairement obsolète. Une entreprise doit définir ce que signifie « suffisamment récent ». Une description de produit peut tolérer un délai de dix minutes ; le stock disponible pendant une vente flash, en revanche, peut nécessiter une mise à jour immédiate.

Les équipes peuvent également utiliser la revalidation à la demande, permettant à un webhook du CMS ou au système de gestion des produits d’actualiser uniquement les pages concernées par une modification.

Une architecture hybride permet également de séparer les parties publiques et privées d’une page. Le contenu principal d’un article ou les informations essentielles d’un produit peuvent être fournis via SSG ou ISR, tandis que les recommandations, les contrôles du compte et les offres spécifiques à la localisation sont chargés séparément.

Cette approche réduit le travail côté serveur sans sacrifier la personnalisation. Elle protège également les performances et l’optimisation pour les moteurs de recherche. Google Search Central explique que les moteurs de recherche traitent JavaScript à travers plusieurs étapes — exploration, rendu et indexation, tout en soulignant que le rendu côté serveur ou le pré-rendu peuvent rendre les sites plus rapides pour les utilisateurs et les robots, et que tous les robots ne sont pas capables d’exécuter JavaScript. « Le rendu côté serveur ou le pré-rendu restent d’excellentes solutions, car ils rendent votre site plus rapide pour les utilisateurs et les robots, et tous les robots ne peuvent pas exécuter JavaScript. » Équipe Google.

La décision d’ingénierie

La bonne question n’est pas de savoir si la SSG, le SSR ou l’ISR est la « meilleure » technologie. La question pertinente est plutôt de déterminer à quelle vitesse chaque page doit évoluer, si sa réponse peut être partagée et quelle quantité de calcul une hausse du trafic doit provoquer.

Pour les contenus dynamiques à fort trafic, la SSG devrait généralement être le choix par défaut pour les pages stables, l’ISR la première option pour les contenus publics fréquemment mis à jour, et le SSR l’outil spécialisé pour les expériences réellement personnalisées ou en temps réel.

Les équipes doivent valider ces choix à partir de mesures en production : taux de cache hit, nombre de requêtes vers l’origine, TTFB p75 et p95, charge de la base de données, échecs de régénération et âge maximal acceptable du contenu.

L’architecture de rendu est finalement une décision métier exprimée dans le code, et les systèmes les plus solides font de la fraîcheur du contenu une politique délibérée, plutôt qu’un effet secondaire accidentel.