Performance Web
Qu’est-ce que SSG (Static Site Generation) ?
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.
Définition simple
C'est comme préparer les plats à l'avance et les garder sous cloche : le HTML est déjà prêt sur le CDN quand le client commande. 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 marche ?
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).
Impact business
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). Un site entièrement servi en fichiers statiques affiche couramment un TTFB sous 100 ms depuis un CDN, ce qui place souvent le LCP dans la zone « bon » sans serveur d'application à chaque clic — et divise parfois par deux ou trois la facture d'hébergement par rapport à une ferme de workers PHP à la requête.
Bonnes pratiques
- 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.
Erreurs communes
- 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.
Prompt IA
Contexte : site [vitrine / blog / landing PSEO], contenu [statique / mis à jour quotidiennement]. Explique le SSG en une phrase. Compare SSG vs SSR pour ce cas : quand régénérer les pages (build, ISR, à la demande) ? Donne un exemple de configuration Next.js (getStaticPaths, revalidate) pour [nombre de pages / fréquence de mise à jour].
SERVICE LIÉ
Passer de la définition à un projet concret.
Création de site internet
Approfondir ce sujet dans le cadre d’un accompagnement adapté à votre contexte.
À LIRE AUSSI
Guides plus complets sur le blog.
QUESTIONS FRÉQUENTES
Aller plus loin sur SSG (Static Site Generation).
Le HTML est prêt dès la première requête : les moteurs reçoivent le contenu complet sans exécuter de JavaScript. Temps de réponse minimal, bon pour le crawl et les Core Web Vitals. Idéal pour les pages ciblées (PSEO, landing).
Soit en relançant un build (déploiement), soit en utilisant l'ISR (Incremental Static Regeneration) : la page est régénérée en arrière-plan après un délai (ex. 1 h). Pour du contenu éditorial, un CMS headless déclenche souvent un rebuild ou une revalidation.
WordPress génère les pages à la requête (ou via cache). Le SSG (Next.js, etc.) génère tout au build : plus rapide et plus sécurisé (pas de PHP en production). Le SSG convient si vous acceptez un workflow de publication via build/déploiement ; WordPress reste pratique pour une mise à jour très fréquente sans technique.