SSG
Définition
Static Site Generation. Génération des pages HTML au moment du build, puis service en pur statique. Maximum de performance, idéal pour les sites dont le contenu change peu.
Comment ça marche
En SSG (Static Site Generation), toutes les pages sont générées au moment du build et servies en pur statique. Au déploiement, le framework parcourt toutes les routes, exécute leur code (récupération de contenu, rendu HTML), et produit des fichiers HTML déjà prêts. Au moment de la visite, aucun calcul serveur n'est nécessaire : un CDN distribue le HTML directement, avec un TTFB sous les 50 ms. C'est l'architecture qui maximise la performance et minimise le coût d'hébergement, au prix d'une fraîcheur figée jusqu'au prochain build.
À quoi ça sert
Le SSG est idéal pour les sites dont le contenu change peu : sites vitrines, blogs, documentations techniques, glossaires, pages marketing, sites institutionnels. Sur Next.js, on génère des centaines de pages à partir d'un fichier de données ou d'un CMS via generateStaticParams. Pour un site de 1000 pages avec un build de deux minutes, on bénéficie d'un site instantané pour le visiteur, d'un coût d'hébergement quasi nul, et d'une fiabilité maximale (un fichier HTML statique ne plante pas). C'est l'option par défaut quand elle est applicable.
Les bénéfices SEO et performance
Le SSG produit le meilleur LCP et le meilleur TTFB possibles : le HTML est déjà prêt, le CDN le pousse depuis le point de présence le plus proche, et le navigateur n'a qu'à le rendre. Google adore ce profil de performance et le récompense dans le classement. Côté coût, héberger 10 000 pages statiques revient à quelques euros par mois sur Vercel, Netlify ou Cloudflare Pages, là où le SSR à ce volume coûterait dix fois plus. La combinaison SSG + Next.js + Vercel est devenue un standard pour les sites SEO ambitieux.
Quand ne pas l'utiliser
Le SSG montre ses limites quand le contenu change souvent ou doit être personnalisé par utilisateur. Pour un catalogue de produits dont le stock change toutes les heures, rebuilder à chaque mise à jour devient impraticable au-delà de quelques centaines de pages. Pour une page "mon compte" qui dépend de l'utilisateur connecté, le SSG n'a aucun sens. Pour des contenus très volumineux (millions de pages), le temps de build devient prohibitif. Dans ces cas, on bascule sur ISR pour les contenus quasi statiques, ou sur SSR pour les pages personnalisées.
Mélanger SSG et autres rendus
Next.js permet de mélanger SSG, ISR et SSR au sein d'une même app, route par route. Le réflexe : SSG par défaut sur les pages publiques, ISR sur les contenus qui évoluent (catalogue, blog éditorial), SSR sur les pages dynamiques (dashboard, recherche, panier). Le framework choisit automatiquement la stratégie selon les appels effectués dans chaque page. On peut aussi forcer le rendu avec la directive export const dynamic = 'force-static' ou 'force-dynamic' quand l'inférence se trompe. La granularité par route évite les arbitrages globaux.
Les limites du build
Un site SSG avec beaucoup de pages voit son temps de build augmenter linéairement. Pour 100 pages, c'est anecdotique. Pour 100 000 pages avec des appels API à chacune, le build peut prendre une heure et bloquer les déploiements. On contourne avec generateStaticParams qui pré-calcule les routes les plus visitées et déporte le reste en ISR avec dynamicParams: true. On parallélise les appels au maximum, on cache agressivement les fetchs identiques, et on déclenche le build uniquement quand un changement le justifie via un webhook CMS, pas à chaque commit.