Le SSG (Static Site Generation) consiste à générer le HTML de toutes les pages une seule fois, au moment du build (déploiement), et à les pousser sur un CDN qui les sert directement aux utilisateurs. Pas de serveur applicatif, pas de base de données interrogée à la volée, pas de calcul à chaque requête : juste des fichiers statiques. C'est le cœur de l'approche Jamstack, supportée nativement par Next.js, Astro, Hugo, Gatsby ou Eleventy.
Les bénéfices sont énormes pour les pages dont le contenu ne change pas à chaque visite : un blog, un site vitrine, une documentation, des landing pages SEO. Le LCP descend sous la seconde, le CLS reste à zéro, le coût d'hébergement Vercel/Cloudflare reste gratuit jusqu'à des volumes importants. Et la sécurité est excellente : sans serveur exécutable, il n'y a rien à pirater. C'est pour ça qu'on l'utilise par défaut sur les sites sur-mesure marketing.
La limite historique — temps de build qui explose au-delà de quelques milliers de pages — a été contournée par l'ISR (Incremental Static Regeneration) chez Next.js, et l'incremental builds chez Astro/Gatsby. On peut aujourd'hui servir 50 000 pages SEO programmatiques en mode SSG hybride sans rebuild complet. Quand le contenu doit être strictement personnalisé par utilisateur, on bascule sur SSR. Mais pour tout ce qui est public et indexable, le SSG reste le meilleur compromis perf/coût/SEO en 2026.
Quand le SSG est le bon choix
- Pages publiques indexables : blog, vitrine, landing, documentation — tout ce qui a vocation à être servi au CDN.
- Volume contenu prévisible : jusqu'à 50 000 pages avec Next.js + ISR, au-delà ça reste possible mais demande de l'archi.
- Performance critique : Core Web Vitals au vert sans optimisation, scores Lighthouse 95+ par défaut.
- Budget hébergement serré : un site SSG bien fait tourne sur l'offre gratuite Vercel/Cloudflare jusqu'à plusieurs millions de visites.
