ISR vs SSG : quelle stratégie de rendu pour un site à fort trafic

Le choix entre Static Site Generation (SSG) et Incremental Static Regeneration (ISR) n'est pas une question de préférence esthétique, c'est un arbitrage entre coût de build, fraîcheur des données et résilience sous charge. Sur une infrastructure Next.js/Vercel, ce choix impacte directement la facture d'edge functions et le comportement du cache CDN. Voici les critères concrets pour trancher.

SSG : le plafond de verre du build

Le SSG génère toutes les pages au build time. Sur un catalogue de 500 pages, c'est trivial. Sur 50 000 pages produits ou articles, le temps de build devient un problème opérationnel :

• Un build Next.js avec generateStaticParams sur 50k routes dynamiques peut dépasser 20-30 minutes selon la complexité des fetchs.
• Chaque déploiement régénère l'intégralité du site, même si 0,1 % du contenu a changé.
• Les limites de build time chez Vercel (45 min sur Pro, configurable sur Enterprise) deviennent un facteur bloquant, pas théorique.

Le SSG reste pertinent quand :

• Le contenu change rarement (documentation technique, pages légales, landing pages marketing figées).
• Le volume de pages reste sous quelques milliers.
• Aucune tolérance à la donnée périmée n'est acceptable même quelques secondes (rare en pratique, mais existe pour des pages de conformité).

ISR : régénération incrémentale et ses paramètres réels

L'ISR découple la génération du build. La page est servie depuis le cache, puis régénérée en arrière-plan selon une politique de revalidation, sans bloquer l'utilisateur suivant (stale-while-revalidate).

Deux mécanismes à connaître précisément :

Revalidation temporelle :

export const revalidate = 60; // secondes

La première requête après expiration reçoit la version en cache (stale) pendant que Next.js régénère en arrière-plan. Le suivant reçoit la version fraîche. C'est transparent, mais ça implique une fenêtre de staleness égale au temps de revalidation, pas nulle.

Revalidation à la demande (revalidatePath, revalidateTag) :

revalidateTag('product-123');

C'est le pattern à privilégier pour du contenu piloté par un CMS ou un ERP : le webhook déclenche l'invalidation exacte de la ressource modifiée, sans attendre un cycle temporel arbitraire. C'est ce qui permet de combiner fraîcheur quasi temps réel et coût de build proche de zéro.

Sur Vercel, chaque régénération consomme une invocation de fonction serverless/edge. Sur un site à fort trafic avec un revalidate: 1, vous générez potentiellement des milliers d'invocations par minute sur les pages chaudes — c'est un coût direct à surveiller dans les métriques d'usage, pas une abstraction gratuite.

Le piège du thundering herd sur les pages à fort trafic

Sur une page avec un trafic élevé et un revalidate court, plusieurs requêtes concurrentes peuvent arriver pendant la fenêtre stale et déclencher plusieurs régénérations en parallèle avant que le cache ne soit mis à jour. Next.js déduplique ces requêtes au niveau du cache de données (fetch avec cache Next.js), mais uniquement si le fetch sous-jacent est correctement mis en cache — un appel direct à une base de données sans passer par une couche de cache applicative (Redis, cache HTTP amont) reproduit le problème.

Recommandation concrète : pour les pages à trafic élevé (top 1 % de vos pages en volume), séparez la stratégie :

• revalidate long (300-3600s) pour absorber la charge.
• revalidateTag déclenché par webhook pour la fraîcheur réelle.
• Cache applicatif (Redis avec TTL court) en amont de la source de données si celle-ci est une API tierce à latence variable.

Arbre de décision opérationnel

| Critère | SSG | ISR | |---|---|---| | Volume de pages | < 5 000 | Illimité | | Fréquence de changement | Rare (jours/semaines) | Fréquente (minutes/heures) | | Contrainte de build time | Aucune | Critique si SSG | | Contenu piloté par CMS/webhook | Non adapté | Adapté via revalidateTag | | Budget invocations serverless | N/A | À monitorer si revalidate court |

En pratique, sur un site B2B à fort trafic avec catalogue dynamique (prix, stocks, contenu éditorial fréquent), l'ISR avec revalidation à la demande est le choix par défaut. Le SSG p