Qu'est-ce que Static Site Generation (SSG) ?

Qu'est-ce que Static Site Generation (SSG) ?

Static Site Generation (SSG) est la pratique de pré-rendre toutes les pages d'un site web en fichiers HTML simples au moment du build, puis de servir ces fichiers directement depuis un CDN sans requêtes de base de données en runtime ni rendu côté serveur. Le résultat : les chargements de page se terminent en dizaines de millisecondes parce que le serveur (l'edge CDN) remet simplement un fichier HTML fini. Aucune logique backend ne tourne par requête. Pas de connexion base de données. Pas de moteur de templates. Juste des octets dedans → des octets dehors.

SSG est une des trois stratégies principales de rendu pour les pages web. Les autres sont SSR (Server-Side Rendering — HTML généré par requête sur le serveur) et CSR (Client-Side Rendering — shell HTML vide avec JavaScript qui fetche et rend les données dans le navigateur). SSG se situe à l'extrémité rapide-pas-cher-sécurisée du spectre : les chargements de page sont imbattablement rapides, les coûts d'hébergement tendent vers zéro, et la surface d'attaque est minimale parce qu'il n'y a aucune logique serveur runtime à exploiter.

Comment fonctionne SSG

L'étape build :

1. Le contenu source vit dans des fichiers. Markdown, YAML, JSON, ou un CMS headless. Designers/rédacteurs éditent le contenu dans un format convivial.
2. Un outil de build lit contenu + templates + données. Next.js, Astro, Hugo, Jekyll, Gatsby, 11ty, Nuxt — tous concurrent dans cet espace. L'outil de build merge les templates avec les données pour produire du HTML.
3. Les pages rendent en fichiers HTML. Un fichier HTML par URL. /blog/post-1.html, /products/widget-x.html, etc.
4. L'output upload vers S3 / CDN. CloudFront, Cloudflare, Netlify, Vercel — le CDN sert les fichiers pré-construits.

L'étape serve (par requête) :

1. Le navigateur demande /blog/post-1.
2. L'edge CDN sert post-1.html. Caché sur l'edge le plus proche, 50 Ko transférés, 10-50 ms total.
3. La page est interactive immédiatement. Pas d'attente pour les round-trips backend. JavaScript hydrate si besoin pour l'interactivité.

Quand SSG est le bon choix

• Sites marketing et blogs. Les mises à jour de contenu sont peu fréquentes (au plus quotidiennes). Build-une-fois-servir-pas-cher correspond au pattern d'accès.
• Sites de documentation. Stripe Docs, Tailwind Docs, la documentation de Stack Overflow sont toutes SSG. La recherche peut utiliser une API séparée ; la documentation elle-même est pré-rendue.
• Catalogues produits e-commerce (principalement). Les pages produit rendent une fois par build. Les données temps réel (inventaire, prix) chargent via des appels API séparés. Les gros sites e-commerce utilisent ce pattern hybride.
• Landing pages SaaS. Le site marketing est SSG ; l'app derrière le login est autre chose (SSR ou CSR).
• Sites qui priorisent Core Web Vitals. SSG produit le LCP et TTFB les plus rapides possibles. Le SEO piloté par CrUX favorise ça.

Là où SSG tombe court

• Contenu qui change par utilisateur. Un dashboard connecté avec des données spécifiques à l'utilisateur ne peut pas être SSG (sans fetching dynamique côté client). Les pages marketing PEUVENT ; le dashboard NE PEUT PAS.
• Contenu temps réel (cours d'actions, scores en direct). SSG nécessiterait des rebuilds toutes les quelques secondes. Utilisez SSR ou WebSockets côté client à la place.
• Très grands sites avec mises à jour fréquentes. Un site avec 1 million de pages dont 10K changent quotidiennement est difficile à faire en SSG pur — les rebuilds complets prennent trop longtemps. Incremental Static Regeneration (ISR — terme Next.js) adresse ça en reconstruisant les pages on-demand dans un SLA.
• Fonctionnalité de recherche. Les sites statiques ne peuvent pas exécuter de recherche côté serveur ; vous aurez besoin soit d'une API de recherche tierce (Algolia, Typesense) soit d'une recherche fuzzy côté client sur un index pré-construit.
• Formulaires et mutations. SSG ne peut pas accepter directement les soumissions de formulaire. Couplez avec un endpoint API séparé de gestion de formulaires ou utilisez un service comme Formspree.

Les gros frameworks SSG (paysage 2026)

• Next.js (React). Hybride SSG/SSR. Le framework basé sur React le plus populaire. Natif Vercel mais fonctionne ailleurs. Lourd mais complet en fonctionnalités.
• Astro. Agnostique des composants (React, Vue, Svelte tous dans un projet). Expédie zéro JavaScript par défaut — Core Web Vitals exceptionnels out of the box.
• Hugo (Go). Binaire compilé, builds incroyablement rapides (1000+ pages par seconde). Capacités dynamiques limitées mais vitesse de build inégalée.
• 11ty (Eleventy, Node). Minimal, flexible. Populaire pour les sites simples qui n'ont pas besoin d'un framework JavaScript sur le client.
• Gatsby (React). Mature, riche en plugins. Largement dépassé par Next.js mais toujours maintenu.
• Nuxt (Vue). La réponse de Vue à Next.js. Hybride SSG/SSR.
• Jekyll (Ruby). Le SSG original. Alimente GitHub Pages par défaut. Vieillissant mais fonctionne encore.

SSG et Core Web Vitals

SSG produit les meilleures métriques CWV du marché :

• LCP : HTML pré-rendu + CSS critique inliné donne typiquement LCP sub-1.5s depuis n'importe quelle région avec couverture CDN.
• FCP : Sub-1s dans la plupart des cas. Le HTML arrive dans le premier paquet.
• CLS : Mêmes contraintes que toute autre stratégie de rendu — dépend du markup, pas de l'approche de build. SSG ne rend CLS ni mauvais ni bon.
• INP : Si le site est principalement statique (pas de JavaScript lourd), INP est excellent. Si le site utilise une hydratation lourde côté client, INP peut être identique à un site CSR.
• TTFB : Meilleur de sa catégorie. HTML caché en CDN sert en millisecondes, bien en dessous de 200 ms même depuis des régions éloignées.

FAQ : Static Site Generation

Quelle est la différence entre SSG et SSR ?

Timing de génération HTML. SSG génère toutes les pages au moment du build ; SSR génère chaque page par requête sur le serveur. SSG est plus rapide (pas de travail par requête) mais stale (contenu fixé au moment du build). SSR est plus frais (données en direct) mais plus lent par requête.

Les sites SSG peuvent-ils être dynamiques ?

Oui — le HTML statique peut inclure du JavaScript qui fetche des données dynamiques après le chargement de la page. Le contenu de base est pré-rendu (bon pour le SEO), et les fonctionnalités dynamiques (compteur de panier, personnalisation) chargent après. C'est le pattern dominant pour l'e-commerce moderne.

Qu'en est-il de SSG avec des millions de pages ?

Les temps de build deviennent un problème. Solutions : Incremental Static Regeneration (Next.js) construit les pages à la première requête et cache ; builds distribués à travers des workers CI (Vercel, Netlify) ; ou accepter que certaines pages vivent en SSR pendant que les populaires restent SSG.

SSG est-il toujours plus rapide que SSR ?

Pour le premier octet et le chargement total de la page, presque toujours oui. Pour la fraîcheur des données, non — SSR peut afficher des données mises à jour il y a des secondes, SSG affiche des données du dernier build. La bonne réponse dépend de votre cas d'usage.

SSG fonctionne-t-il avec la personnalisation ?

Oui, via le chargement de données côté client. Le HTML partagé est SSG ; les éléments spécifiques à l'utilisateur (son nom, son panier, ses recommandations) chargent via JavaScript après le chargement de la page. Même pattern que les pages de checkout Stripe, les docs Notion, etc.

Quel est le piège avec SSG ?

Les temps de build évoluent linéairement avec la taille du contenu. Les sites avec 100K+ pages ont besoin de stratégies de build soigneuses. Les mises à jour de contenu nécessitent un déploiement (ou ISR). Et les fonctionnalités dynamiques (formulaires, recherche, commentaires) ont besoin d'infrastructure séparée.

Comment LoadFocus mesure la performance SSG

LoadFocus exécute des tests de vitesse basés sur Lighthouse depuis 25+ régions, capturant TTFB, LCP, INP et CLS. Les sites SSG affichent typiquement dans le décile supérieur des scores CWV — mais vous devriez vérifier à travers les régions parce que la couverture CDN varie. Les tests de charge avec JMeter/k6 confirment aussi que votre CDN gère bien le trafic en pic — SSG avec un CDN solide est l'un des rares stacks qui gère les pics de trafic 10x avec grâce.