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.
Point clé : Astro est le choix par défaut moderne pour les sites de contenu, Hugo remporte la course à la vitesse de compilation brute, Eleventy gagne en simplicité sans configuration, et Gatsby est en déclin progressif ; choisissez selon votre équipe et votre modèle de contenu.
Le tableau honnête de 2026 : Astro a remporté définitivement le segment « moderne », Hugo a remporté définitivement le segment « rapide et agnostique au langage », Eleventy est la bonne réponse pour la niche des curieux de JavaScript mais réticents à la configuration, Gatsby est en déclin progressif, et Jekyll est désormais utilisé principalement pour GitHub Pages et les projets legacy. La comparaison à cinq entrées est honnêtement plutôt « choisissez Astro, sauf si vous avez une raison spécifique », mais les raisons sont réelles et méritent d'être connues. Le framework hub couvre la décision plus large sur les frameworks ; ce post concerne spécifiquement le sous-ensemble des générateurs de sites statiques.
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, Content Layer API. Le standard pour les nouveaux sites de contenu en 2026.
- Eleventy (11ty), basé sur JavaScript, configuration légère, aucun JS de build-time expédié au client. Le bon choix pour les développeurs qui veulent la familiarité avec JS sans surcharge React ou Vue.
- Hugo, basé sur Go, les builds les plus rapides de la catégorie, 5 à 10 fois plus vite, pas de dépendance Node. Le bon choix pour les sites avec beaucoup de contenu où le temps de build compte vraiment.
- Jekyll, basé sur Ruby, natif à GitHub Pages, écosystème de templates mature. Utilisé principalement 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 progressif depuis l'acquisition par Netlify en 2023. Toujours stable en production mais plus le standard pour les nouveaux projets.
Où chaque SSG excelle vraiment
Astro : 91 000 pages de preuve en production
Astro est le SSG vers lequel la plupart des gens se tournent maintenant par défaut pour les nouveaux projets en 2026. L'architecture, zéro-JS par défaut avec des îles optionnelles d'interactivité, est la bonne forme pour la majorité des sites de contenu. La Content Layer API remplace les Content Collections et extrait le contenu de n'importe quelle source avec type safety. Les Server Islands vous permettent de rendre certaines parties d'une page statique au moment de la requête sans transformer toute la page en page dynamique. HostList.io tourne sur Astro 5 avec 91 000 pages, Lighthouse mobile médian 92, temps de build autour de 18 minutes pour un rebuild complet, ~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 build est le goulot d'étranglement. Un site Astro de 5 000 pages se build en 4-7 minutes ; le même site dans Hugo se build en 30-90 secondes. Pour les sites au-delà de 20 000 pages où la fréquence de déploiement est quotidienne ou horaire, la différence est celle entre un pipeline CI qui fonctionne et un qui coûte 200 $ en minutes de build par mois. Le compromis est le langage de templating (templates Go) et l'écosystème moderne plus petit, les plugins et intégrations de Hugo ont plutôt une forme utilitaire 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.
- Laisse à désirer sur : la plupart des besoins modernes, des builds plus lents qu'Hugo, un outillage plus daté qu'Astro, un écosystème plus petit que l'un ou l'autre.
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 nombre significatif. La couche de données GraphQL qui était le point fort de Gatsby en 2018 est désormais largement considérée comme excessive pour les sites de contenu ; l'API Content Layer d'Astro et le fetching de données de Next.js couvrent le même terrain sans la surcharge GraphQL. Le bon choix uniquement 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 selon la taille des builds et 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.
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ù c'est encore 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 annoncé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 orientées 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 d'Hugo pour le projet web typique de 2026. Pour les sites dépassant 20K pages où le temps de build est un vrai coût, Hugo gagne sur la vitesse brute de compilation avec un facteur 5-10x. Le choix dépend de l'équipe et de l'échelle ; les deux sont légitimement la bonne réponse pour des briefs différents.
Dois-je migrer de Gatsby à Astro ?
Uniquement si le site Gatsby cause des vrais problèmes, des builds lents, une complexité GraphQL que l'équipe ne peut pas maintenir, une dérive des dépendances qui devient un problème de sécurité. Pour les sites Gatsby qui fonctionnent, le coût de migration de 4-8 semaines en vaut rarement la peine. La communauté Gatsby a avancé mais le framework reste stable en production.
Pourquoi Hugo est-il tellement plus rapide qu'Astro ?
Hugo est écrit en Go, se compile en un binaire unique, et utilise le moteur de templating de Go qui est optimisé pour la génération de texte statique. Astro est basé sur JavaScript, s'exécute via Node, et utilise les renderers React/Vue/Svelte selon les besoins. La différence d'architecture fondamentale est réelle et ne disparaît pas, Astro ne rattrapera pas Hugo sur la vitesse de build parce que les langages sont différents. La réponse Astro c'est « suffisamment bon pour la plupart des sites » ; Hugo c'est « nettement plus rapide quand ça 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 s'exécute sur n'importe quel hôte compatible Ruby. Pratiquement rare en 2026. Si vous ne déployez pas sur GitHub Pages, l'équivalent moderne c'est Astro sur Cloudflare Pages ou le tier gratuit de Netlify, qui vous donne un build 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'étend au-delà des SSG purs.
Web Frameworks Hub, l'arbre décisionnel plus large des frameworks, avec contexte SSG.
Headless WordPress + Astro : une configuration fonctionnelle, approche pratique si votre choix SSG est Astro associé à un CMS.
Comment j'ai construit un annuaire de 25 000 pages en Next.js, étude de cas en production à grande échelle ; utile pour le contexte de décision SSG-vs-Next.js.
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 forme du site, l'équipe, la fréquence de compilation, la cible de déploiement. Repartez avec une décision Astro-vs-Hugo-vs-Eleventy adaptée à votre contexte.