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

Qu'est-ce que la génération de site statique (SSG) ?

La génération de site statique (SSG, pour Static Site Generation) est une approche de rendu où une étape de build transforme à l'avance votre contenu et vos modèles en fichiers HTML. Ces fichiers sont déposés sur un hébergeur ou un CDN et servis tels quels : aucun code ni requête de base de données ne s'exécute quand un visiteur demande une page. C'est l'une des stratégies de rendu web.

Comment fonctionne le SSG

1. Le contenu vit dans des fichiers source ou un CMS. Markdown, JSON, YAML ou l'API d'un CMS headless.
2. Un outil de build combine contenu, modèles et données. Il écrit un fichier HTML par URL, avec le CSS, le JavaScript et les images.
3. Le résultat est déployé. Les fichiers vont sur un stockage objet ou un hébergeur statique, en général derrière un CDN.
4. Chaque requête est une lecture de fichier. Le point de présence renvoie le fichier déjà construit : le temps jusqu'au premier octet dépend surtout de la distance réseau.

Des frameworks comme Astro, Hugo, Eleventy, Jekyll, Next.js et Nuxt savent produire une sortie statique. D'après sa documentation sur les îlots, Astro rend les composants en HTML et CSS et n'envoie du JavaScript que pour les parties que vous marquez comme interactives. Dans Next.js, avec output: 'export', next build écrit un dossier statique de HTML, CSS et JavaScript.

Quand le SSG est le bon choix

• Sites marketing, blogs et documentation : le contenu change selon un calendrier de publication, pas par visiteur.
• Pages d'atterrissage qui doivent être rapides : du HTML prêt à l'emploi servi par un CDN est le chemin le plus court vers le premier octet.
• Catalogues ou listes avec prix ou stock appelés côté client : la structure est statique et une petite requête d'API apporte les données en direct.
• Sites qui veulent un hébergement simple et peu coûteux : un hébergeur statique n'a pas de serveur d'application à patcher ni à dimensionner.

Les limites du SSG

• Contenu propre à chaque utilisateur. Un tableau de bord connecté ne peut pas être pré-construit pour chaque utilisateur. Utilisez le rendu côté serveur ou chargez les données dans le navigateur.
• Données en direct. Des scores ou des niveaux de stock qui changent toutes les quelques secondes demandent du SSR ou une requête côté client.
• Très gros sites qui changent vite. Reconstruire des milliers de pages à chaque modification devient lent. La régénération statique incrémentale ne reconstruit que les pages modifiées.
• Fonctions serveur. L'export statique n'a aucune logique au moment de la requête. Next.js indique que les cookies, redirections, réécritures, en-têtes, server actions et l'ISR ne sont pas pris en charge avec output: 'export' : on les gère donc chez l'hébergeur ou au CDN.

Exemple : un site de documentation

Une documentation compte 400 pages Markdown. Le build les convertit en 400 fichiers HTML, un job de CI les envoie sur le stockage et le CDN les met en cache dans le monde entier. Quand une rédactrice corrige une coquille, la chaîne reconstruit et redéploie, puis le cache du CDN est purgé pour les chemins modifiés. La recherche passe par un index pré-construit dans le navigateur ou une API de recherche hébergée.

Erreurs fréquentes

• Oublier d'invalider le cache du CDN après un déploiement : les visiteurs voient toujours l'ancienne page.
• Appeler pendant le build une API tierce lente sans délai maximal : une seule panne fait échouer tout le build.
• Croire que statique rime avec sécurisé par défaut : l'hébergement, les formulaires et les API restent à protéger.
• Charger de gros bundles JavaScript sur une page statique et perdre l'avantage de vitesse.
• Figer dans le code des données qui devraient être récupérées à la demande, comme les prix.

SSG, tests de performance et supervision

Les pages statiques suppriment l'essentiel de la variabilité du backend : surveillez donc le taux de succès du cache CDN, le temps jusqu'au premier octet depuis plusieurs régions et le poids de ce que vous envoyez. Suivez la vitesse de page et les Core Web Vitals après chaque déploiement avec LoadFocus Page Speed Monitoring, qui lance des audits Lighthouse planifiés depuis 25 régions cloud. L'article conseils pour la vitesse de page (en anglais) couvre le travail front-end qui compte toujours sur un site statique.

Si un site statique appelle des API pour la recherche, les formulaires ou des données en direct, la charge se voit sur ces points d'accès. Lancez un test de charge dessus avant un pic de trafic.

Questions fréquentes : génération de site statique

Quelle est la différence entre SSG et SSR ?

Le moment. Le SSG génère le HTML une fois, avant l'arrivée de tout visiteur. Le SSR le génère sur le serveur à chaque requête. Le SSG est moins cher et plus rapide à servir, le SSR peut afficher des données propres à la requête ou en temps réel.

Un site statique est-il un site sans JavaScript ?

Non. Un site statique peut exécuter du JavaScript dans le navigateur pour des menus, une recherche ou des widgets. Statique signifie que le HTML est construit à l'avance, pas que la page n'est pas interactive.

Le SSG est-il bon pour le SEO ?

Oui. Les robots reçoivent immédiatement un HTML complet et des pages rapides aident les Core Web Vitals. Le SSG ne suffit pas à positionner une page pour autant : la qualité du contenu et les liens restent déterminants.

Comment mettre à jour le contenu d'un site statique ?

Modifiez la source, lancez le build et déployez les nouveaux fichiers. La plupart des hébergeurs et systèmes de CI le font automatiquement à chaque commit ou à la publication dans votre CMS. Sur de très gros sites, la régénération incrémentale ne reconstruit que ce qui a changé.

Un site statique peut-il avoir des formulaires, une recherche ou une connexion ?

Oui, en appelant des API depuis le navigateur ou en utilisant des services hébergés pour les formulaires et la recherche. La page reste statique et la partie dynamique s'exécute ailleurs.