Les posts de comparaison de générateurs de sites statiques en 2026 ressemblent surtout à un article d'évangélisation Hugo de 2018 mis à jour avec un paragraphe Astro à la fin. Ceci est la version après avoir fait tourner un site Astro de 91 000 pages (HostList.io) en production, plus le lancement de projets plus petits sur Eleventy, Hugo et Gatsby dans le travail client des deux dernières années. Cinq générateurs, vraies données de production, pas de nostalgie.
Le tableau honnête 2026 : Astro a gagné le segment 'moderne' de manière définitive, Hugo a gagné le segment 'rapide et agnostique au langage' de manière définitive, Eleventy est la bonne réponse pour la niche des curieux-JavaScript-mais-réticents-à-la-config, Gatsby est en déclin lent, et Jekyll est maintenant surtout utilisé pour GitHub Pages et les projets legacy. La comparaison à cinq est franchement plus du style 'choisissez Astro, sauf si vous avez une raison spécifique' — mais les raisons sont réelles et valent le coup d'être connues. Le hub des frameworks couvre la décision plus large sur les frameworks ; ce post concerne spécifiquement le sous-ensemble des générateurs de sites statiques.The framework hub covers the broader framework decision; this post is specifically about the static-site-generator subset.
Les cinq SSG en 60 secondes
- Astro — modèle de composants multi-framework (React, Vue, Svelte, Solid), zéro-JS par défaut avec architecture en îles, API Content Layer. Le défaut pour les nouveaux sites de contenu en 2026.
- Eleventy (11ty) — basé sur JavaScript, configuration légère, aucun JS de temps de build expédié au client. Le bon choix pour les ingénieurs qui veulent la familiarité JavaScript sans la surcharge de React ou Vue.
- Hugo — basé sur Go, les builds les plus rapides de la catégorie avec un ratio de 5-10x, pas de dépendance Node. Le bon choix pour les sites lourds en contenu où le temps de build compte vraiment.
- Jekyll — basé sur Ruby, natif à GitHub Pages, écosystème de templates mature. Surtout utilisé pour les projets legacy et l'hébergement gratuit GitHub Pages en 2026.
- Gatsby — basé sur React avec couche de données GraphQL, en déclin depuis l'acquisition Netlify en 2023. Toujours stable en production mais n'est plus le par défaut pour les nouveaux projets.
Où chaque SSG excelle vraiment
Astro : 91 000 pages de preuve en production
Astro est maintenant le SSG par défaut pour la plupart des nouveaux projets en 2026. L'architecture — zéro-JS par défaut avec îlots optionnels d'interactivité — a la bonne forme pour la majorité des sites de contenu. L'API Content Layer remplace Content Collections et récupère le contenu de n'importe quelle source avec type safety. Les Server Islands vous permettent de rendre des parties d'une page statique à la demande sans escalader la page entière en dynamique. HostList.io tourne sur Astro 5 avec 91 000 pages, Lighthouse mobile médian 92, temps de build autour de 18 minutes pour une reconstruction complète, ~80KB de JavaScript client par route en moyenne.
- Excelle sur : les sites de contenu modernes à toute échelle, l'SEO programmatique, la flexibilité multi-framework, l'écosystème qui a toutes les intégrations modernes.
- Reste en retrait sur : la vitesse de build au niveau Hugo (Astro à 5K pages c'est 4-7 minutes vs 30-60 secondes pour Hugo), les shops Ruby et Go où Node n'est pas le bon par défaut.
Eleventy : JavaScript sans l'overhead du framework
Eleventy est le SSG pour les ingénieurs qui veulent du templating basé JavaScript sans s'engager sur React, Vue, ou un modèle de composant spécifique. La configuration est véritablement minimale, le pipeline de build est simple, et la sortie est du HTML propre par défaut. Le bon choix pour les sites en forme de blog, la documentation, et les petits sites marketing où 'je veux juste du HTML' est le brief et le modèle de composant d'Astro semble excessif.
- Avantages : familiarité avec JavaScript sans surcharge de framework, sites de blogs et de documentation simples, approche légère en configuration.
- Faiblesses : composants interactifs complexes (vous apportez votre propre approche), petits écosystèmes d'intégrations prédéfinies par rapport à Astro.
Hugo : vitesse de compilation quand cela compte vraiment
Hugo est le SSG pour les sites où le temps de compilation est le goulot d'étranglement. Un site Astro de 5 000 pages se compile en 4-7 minutes ; le même site dans Hugo se compile en 30-90 secondes. Pour les sites dépassant 20 000 pages où le déploiement est quotidien ou horaire, la différence est celle entre un pipeline CI qui fonctionne et un qui coûte 200 dollars en minutes de compilation par mois. Le compromis est le langage de templating (Go templates) et le petit écosystème moderne — les plugins et intégrations de Hugo sont plutôt utilitaires par rapport aux intégrations modernes riches que vous obtenez avec Astro.
- Avantages : vitesse de compilation à grande échelle, équipes agnostiques du langage, sites dépassant 20 000 pages où le temps de compilation est un vrai coût.
- Faiblesses : modèle de composant moderne (Go templates semblent datés pour les ingénieurs habitués à JSX), adoption en petites équipes (moins d'ingénieurs connaissent Go templates que JSX).
Jekyll : support natif de GitHub Pages et maintenance d'héritage
Jekyll est surtout utilisé en 2026 pour deux raisons : support natif de GitHub Pages (hébergement gratuit si votre site est façonné pour Jekyll), et maintenance d'héritage de sites construits à l'origine quand Jekyll était le standard. Pour un nouveau projet en 2026, le seul choix Jekyll est « je veux un hébergement gratuit sur GitHub Pages ». Astro sur Cloudflare Pages ou Netlify gratuit est généralement l'équivalent moderne.
- Avantages : hébergement gratuit sur GitHub Pages, maintenance de sites hérités.
- Faiblesses : plupart des besoins modernes — compilations plus lentes que Hugo, outils plus datés qu'Astro, petit écosystème par rapport aux deux.
Gatsby : production-stable, déclin progressif
Gatsby est en déclin lent depuis l'acquisition par Netlify en 2023. Le framework est stable et les sites en production continuent de fonctionner, mais les nouveaux projets ne choisissent pas Gatsby en nombres significatifs. La couche de données GraphQL qui était le différenciateur de Gatsby en 2018 est désormais considérée comme overkill pour la plupart des sites de contenu — l'API Content Layer d'Astro et la récupération de données de Next.js couvrent le même terrain sans la surcharge GraphQL. C'est le bon choix seulement si vous avez déjà un site Gatsby et que la migration n'en vaut pas la peine.
- Points forts : les sites Gatsby existants où le coût de migration n'en vaut pas la peine.
- Points faibles : les nouveaux projets (la communauté s'est déplacée), la vélocité des fonctionnalités (le rythme de développement a ralenti depuis l'acquisition).
L'arbre de décision — choisir en fonction de la taille de build et de la structure de l'équipe
Site de contenu moderne de moins de 10K pages, équipe à l'aise avec JavaScript
Astro. Le choix par défaut. Utilisez l'API Content Layer pour n'importe quelle source de contenu, les Server Islands pour le contenu dynamique occasionnel, et l'écosystème d'intégrations pour tout le reste. C'est le cas à 80% en 2026.
Site dépassant 20K pages avec des déploiements quotidiens
Hugo si votre équipe est à l'aise avec les templates Go. HostList à 91K pages se construit en 18 minutes sur Astro ; le même site sur Hugo se construirait en 2-3 minutes. À cette échelle, l'économie de Hugo devient significativement meilleure pour les coûts CI.HostList at 91K pages on Astro builds in 18 minutes; the same site on Hugo would build in 2-3 minutes. At that scale Hugo's economics get meaningfully better for CI cost.
Site de blog ou de documentation, aversion pour la configuration
Eleventy. Basé sur JavaScript, configuration minimale, sortie HTML propre. Exactement ce qu'il faut quand le brief se résume à « je veux juste du HTML ».
Hébergement gratuit sur GitHub Pages requis
Jekyll. La seule catégorie où il reste le standard en 2026 — le support natif de GitHub Pages signifie zéro infrastructure d'hébergement à maintenir.
Site Gatsby existant
Restez sur Gatsby sauf si la migration est vraiment nécessaire. Migrer de Gatsby vers Astro est réaliste en 4-8 semaines pour un site de taille typique, mais le coût de migration en vaut rarement la peine pour les sites en production qui fonctionnent.
Benchmarks de temps de build — mesurés, pas affirmés
Basés sur un site de contenu hypothétique avec 5 000 pages, optimisation des images activée, déploiement sur un runner CI typique.
- Hugo : 30-60 secondes pour le build complet. Le traitement des images se fait en parallèle. Vraiment le plus rapide de la catégorie.
- Eleventy : 1-3 minutes. Basé sur JavaScript, mais overhead minimal.
- Astro : 4-7 minutes. Le pipeline d'optimisation des images et l'étape de build du Content Layer sont les parties lourdes.
- Jekyll : 3-8 minutes. Plus lent qu'Eleventy, plus rapide que Gatsby, le démarrage Ruby ajoute une surcharge notable.
- Gatsby : 8-15 minutes. La couche de données GraphQL ajoute du temps réel à cette échelle.
À 50K pages, l'écart s'élargit dramatiquement. Hugo à ~3-5 minutes ; Astro à ~25-40 minutes ; Gatsby au-delà de 60 minutes. Pour les sites de production avec une fréquence de déploiement quotidienne ou plus, c'est la différence entre une boucle CI utile et une qui devient le goulot d'étranglement.
FAQ
Astro est-il meilleur que Hugo ?
Pour les sites de contenu modernes avec des équipes façonnées par JavaScript, oui — le modèle de composants d'Astro, l'API Content Layer, et l'écosystème d'intégrations sont tous plus utiles que le templating Go de Hugo pour le projet web typique de 2026. Pour les sites au-delà de 20K pages où le temps de compilation est un vrai coût, Hugo gagne en vitesse de compilation brute de 5-10x. Le choix dépend de l'équipe et de l'échelle ; les deux sont légitimement la bonne réponse pour différents cahiers des charges.
Dois-je migrer de Gatsby à Astro ?
Seulement si le site Gatsby cause des problèmes réels — des compilations lentes, une complexité GraphQL que l'équipe ne peut pas maintenir, une dérive des dépendances qui devient une préoccupation de sécurité. Pour les sites Gatsby qui fonctionnent, le coût de migration de 4-8 semaines ne vaut rarement la peine. La communauté Gatsby a avancé mais le framework est toujours stable en production.
Pourquoi Hugo est-il tellement plus rapide qu'Astro ?
Hugo est écrit en Go, se compile en un seul binaire, et utilise le moteur de templating de Go optimisé pour la génération de texte statique. Astro est basé sur JavaScript, s'exécute via Node, et utilise les rendeurs React/Vue/Svelte selon les besoins. La différence architecturale fondamentale est réelle et ne se comble pas — Astro ne rattrapera pas Hugo en vitesse de compilation parce que les langages sont différents. La réponse d'Astro est « assez bon pour la plupart des sites » ; Hugo est « sensiblement plus rapide quand cela compte ».
Eleventy est-il encore pertinent en 2026 ?
Oui pour les ingénieurs qui veulent spécifiquement un SSG JavaScript léger en configuration, sans le modèle de composants d'Astro. Eleventy est plus « donne-moi juste du HTML » qu'Astro, et cette simplicité est vraiment appréciée par certaines équipes. Pour la plupart des sites de contenu modernes, Astro est le choix par défaut plus puissant ; pour les sites de type blog où la simplicité est l'objectif explicite, Eleventy gagne toujours.
Puis-je utiliser Jekyll en dehors de GitHub Pages ?
Techniquement oui — Jekyll fonctionne sur n'importe quel hébergement capable de Ruby. Pratiquement rare en 2026. Si vous ne déployez pas sur GitHub Pages, l'équivalent moderne est Astro sur Cloudflare Pages ou la couche gratuite de Netlify, ce qui vous donne une compilation plus rapide, une chaîne d'outils plus moderne, et la même histoire d'hébergement gratuit.
Lectures connexes
Next.js vs Remix vs Astro en 2026 — la comparaison de frameworks quand le choix s'élargit au-delà des SSG purs. — the framework comparison when the choice expands beyond pure SSGs.
Hub des frameworks web — l'arbre de décision plus large des frameworks, avec contexte SSG. — the broader framework decision tree, with SSG context.
WordPress découplé + Astro : une configuration qui fonctionne — configuration pratique si votre choix SSG est Astro associé à un CMS. — practical setup if your SSG choice is Astro paired with a CMS.
Comment j'ai construit un annuaire de 25 000 pages en Next.js — étude de cas de production à grande échelle ; utile pour le contexte de décision SSG vs Next.js. — production case study at scale; useful for SSG-vs-Next.js decision context.
Le choix SSG est une décision de temps de compilation et de structure d'équipe, pas une décision de fonctionnalités. Choisissez en fonction de ce que votre équipe maintiendra réellement au cours des deux prochaines années.
Réservez un appel de 30 minutes pour choisir votre SSG — décrivez la structure du site, l'équipe, la fréquence de build, la cible de déploiement. Vous repartirez avec une décision Astro-vs-Hugo-vs-Eleventy qui correspond à votre brief. — describe the site shape, the team, the build frequency, the deploy target. Walk away with an Astro-vs-Hugo-vs-Eleventy decision that fits the brief.