Définition technique
Technique de rendu où les pages HTML sont générées au moment du build (ou à la demande en arrière-plan), pas à chaque requête. Le serveur ou le CDN envoie alors un fichier déjà prêt : temps de réponse minimal, charge serveur faible, idéal pour le référencement et la vitesse. Next.js, Gatsby, Astro proposent du SSG. Adapté aux sites à contenu stable (vitrine, blog, documentation) ; pour du contenu très dynamique (stock, prix en direct), on combine SSG avec revalidation (ISR) ou des zones dynamiques.
Comment ça fonctionne ?
Lors du build, le framework génère un fichier HTML (et assets) pour chaque page définie (routes statiques, ou toutes les entrées d'un blog). Ces fichiers sont déployés sur un serveur ou un CDN. À la requête, le serveur renvoie le fichier tel quel, sans exécuter de logique métier. Option ISR : régénérer en arrière-plan après un délai (ex. 3600 s).
L'erreur classique à éviter
Utiliser du SSG pour des pages qui doivent afficher des données en temps réel (stock, prix) sans prévoir de zone dynamique ou de revalidation. Builds très longs si des milliers de pages sans découpage.
Impact business : pourquoi s'en soucier ?
Un site en SSG est rapide et peu coûteux à héberger (CDN statique). C'est la base de la stratégie PSEO (pages statiques ciblées géographiquement ou thématiquement). Pour un blog, une vitrine ou des landing pages, le SSG offre le meilleur rapport performance / coût. Les mises à jour se font au rebuild ou via une revalidation incrémentale (ISR).
La règle d'or
Choisir le SSG pour le contenu stable. Utiliser getStaticPaths avec fallback si besoin. Activer l'ISR (revalidate) pour un contenu qui change périodiquement. Héberger sur un CDN pour maximiser la vitesse.