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

La génération de site statique pré-rend chaque page en HTML brut au moment du build, avant toute requête utilisateur. Les fichiers obtenus sont déposés sur un stockage objet ou un content-delivery-network-cdn et servis comme des réponses cacheables et déterministes. Pour le commerce, la SSG fonctionne le mieux sur du contenu qui change à un rythme éditorial plutôt que transactionnel.

Définition

Pendant l'étape de build, le framework parcourt un ensemble de routes, récupère les données auprès des API commerce, du content-management-system-cms et des catalogues produit, et écrit un document HTML autonome plus un bundle d'hydratation par page. Des outils comme Next.js getStaticProps, Astro, Nuxt nuxt generate, Gatsby et Hugo sont des implémentations SSG typiques. Les pages sont servies depuis des caches edge avec un TTFB de quelques dizaines de millisecondes et un coût de rendu nul. La SSG est une pierre angulaire du jamstack et se marie naturellement avec un content-delivery-network-cdn pour la distribution mondiale.

Pourquoi c'est important

La SSG supprime entièrement le coût de rendu à l'exécution, ce qui se traduit par un TTFB prévisible, une mise à l'échelle horizontale facile et des factures d'hébergement plus basses. Pour les Core Web Vitals, c'est la stratégie de rendu la plus indulgente car le LCP est surtout borné par la livraison des assets. C'est le bon choix pour les pages marketing, les entrées de glossaire, les histoires de marque, les landing-pages SEO et le contenu catégorie evergreen. La SSG resserre aussi la surface de sécurité, car il n'y a pas de runtime live par requête. Le compromis est la fraîcheur : tout changement de catalogue exige un rebuild, ce qui limite la SSG pour les PDP sensibles au stock.

Cas d'usage

Les équipes composable-commerce génèrent généralement en SSG leur réseau de landing-pages, le blog, les centres d'aide et les pages catégorie à plus faible trafic sur Astro, Next.js ou Nuxt, puis les déploient via Vercel, Netlify ou Cloudflare Pages. Des webhooks d'un CMS headless déclenchent des builds incrémentaux quand les éditeurs publient, pour que le TTFB reste proche de zéro pendant que le contenu reste frais. Pour les PDP, les équipes passent soit à l'ISR pour une revalidation plus fine, soit combinent des shells SSG avec des fetches côté client pour le stock et les prix. La SSG est aussi le choix par défaut des architectures de référence jamstack qui associent Hygraph, Sanity ou Contentful à un frontend statique.

Voir aussi

Découvrez Composable Headless Frontend · Performance and Core Web Vitals.