Posts de comparação de geradores de site estático em 2026 geralmente leem como um texto de evangelismo Hugo de 2018 atualizado com um parágrafo Astro no final. Esta é a versão depois de rodar um site Astro de 91.000 páginas (HostList.io) em produção, mais lançamento de projetos menores em Eleventy, Hugo, e Gatsby em trabalho de cliente nos últimos dois anos. Cinco geradores, dados de produção real, sem nostalgia.
O retrato honesto de 2026: Astro venceu o segmento 'moderno' definitivamente, Hugo venceu o segmento 'rápido e agnóstico de linguagem' definitivamente, Eleventy é a resposta certa para o nicho JavaScript-curioso-mas-avesso-a-configuração, Gatsby está em declínio suave, e Jekyll é usado principalmente agora para GitHub Pages e projetos legados. A comparação em cinco vias é honestamente mais como 'escolha Astro, a menos que você tenha um motivo específico' — mas os motivos são reais, e vale a pena conhecê-los. O framework hub cobre a decisão de framework mais ampla; este post é especificamente sobre o subconjunto de gerador de site estático.The framework hub covers the broader framework decision; this post is specifically about the static-site-generator subset.
Os cinco SSGs em 60 segundos
- Astro — modelo de componente multi-framework (React, Vue, Svelte, Solid), zero-JS por padrão com arquitetura de ilhas, Content Layer API. O padrão para novos sites de conteúdo em 2026.
- Eleventy (11ty) — baseado em JavaScript, configuração leve, nenhum JS em tempo de build enviado para o cliente. A escolha certa para engenheiros que querem familiaridade com JS sem overhead de React ou Vue.
- Hugo — baseado em Go, as compilações mais rápidas da categoria por 5-10x, sem dependência de Node. A escolha certa para sites com muito conteúdo onde o tempo de compilação realmente importa.
- Jekyll — baseado em Ruby, nativo do GitHub Pages, ecossistema de templates maduro. Usado principalmente para projetos legados e hospedagem gratuita no GitHub Pages em 2026.
- Gatsby — baseado em React com camada de dados GraphQL, em declínio suave desde a aquisição da Netlify em 2023. Ainda estável para produção, mas não é mais o padrão para novos projetos.
Onde cada SSG realmente vence
Astro: 91.000 páginas de prova em produção
Astro é o SSG para o qual a maioria das pessoas agora opta por padrão para novos projetos em 2026. A arquitetura — zero JS por padrão com ilhas opcionais de interatividade — é a forma certa para a maioria dos sites de conteúdo. A Content Layer API substitui Content Collections e puxa conteúdo de qualquer fonte com segurança de tipo. Server Islands permitem que você renderize partes de uma página estática no tempo da requisição sem escalar toda a página para dinâmica. HostList.io roda em Astro 5 com 91.000 páginas, Lighthouse mobile mediano 92, tempo de compilação em torno de 18 minutos para uma reconstrução completa, ~80KB de JavaScript client por rota em média.
- Vence em: sites de conteúdo moderno em qualquer escala, SEO programático, flexibilidade multi-framework, o ecossistema que tem todas as integrações modernas.
- Fica aquém em: velocidade de compilação no nível do Hugo (Astro em 5K páginas fica em torno de 4-7 minutos vs 30-60 segundos do Hugo), lojas Ruby e Go onde Node é o padrão errado.
Eleventy: JavaScript sem o overhead do framework
Eleventy é o SSG para engenheiros que querem templating baseado em JavaScript sem se comprometer com React, Vue ou qualquer modelo de componente específico. A configuração é genuinamente mínima, o pipeline de compilação é simples e o output é HTML limpo por padrão. A escolha certa para sites em formato de blog, documentação e pequenos sites de marketing onde 'eu só quero HTML' é o brief e o modelo de componentes do Astro parece overkill.
- Vence em: familiaridade com JavaScript sem overhead de framework, sites de blog e documentação simples, abordagem leve em configuração.
- Fica a desejar em: componentes interativos complexos (você traz sua própria abordagem), ecossistemas grandes de integrações pré-construídas versus Astro.
Hugo: velocidade de build quando realmente importa
Hugo é o SSG para sites onde o tempo de build é o gargalo. Um site Astro com 5.000 páginas é feito em 4-7 minutos; o mesmo site em Hugo é feito em 30-90 segundos. Para sites com mais de 20.000 páginas onde a frequência de deploy é diária ou horária, a diferença é entre um pipeline de CI que funciona e um que custa $200 em minutos de build por mês. O trade-off é a linguagem de templates (Go templates) e o ecossistema moderno menor — os plugins e integrações do Hugo tendem à forma utilitária em vez das integrações ricas e modernas que você consegue com Astro.
- Vence em: velocidade de build em escala, times agnósticos de linguagem, sites com mais de 20K páginas onde o tempo de build é um custo real.
- Fica a desejar em: modelo de componente moderno (Go templates parecem datados para engenheiros acostumados com JSX), adoção em times pequenos (menos engenheiros conhecem Go templates do que conhecem JSX).
Jekyll: GitHub Pages e manutenção legada
Jekyll é usado principalmente em 2026 por duas razões: suporte nativo do GitHub Pages (hosting gratuito se seu site é do formato Jekyll) e manutenção legada de sites originalmente feitos quando Jekyll era o padrão. Para um novo projeto em 2026, a única razão para escolher Jekyll é 'eu quero hosting gratuito no GitHub Pages'. Astro em Cloudflare Pages ou camada gratuita do Netlify é geralmente o equivalente moderno.
- Vence em: hosting gratuito no GitHub Pages, manutenção de sites legados.
- Fica a desejar em: a maioria das necessidades modernas — builds mais lentos que Hugo, ferramental mais datado que Astro, ecossistema menor que qualquer um dos dois.
Gatsby: estável em produção, declínio suave
Gatsby está em declínio lento desde a aquisição pela Netlify em 2023. O framework é estável e sites em produção continuam funcionando, mas novos projetos não estão adotando Gatsby em números significativos. A camada de dados GraphQL que era o diferencial do Gatsby em 2018 agora é considerada mostly overkill para sites de conteúdo — a Content Layer API do Astro e o data fetching do Next.js cobrem o mesmo terreno sem o overhead do GraphQL. A decisão correta apenas quando você já tem um site Gatsby e migrar não compensa.
- Pontos fortes: sites Gatsby existentes onde o custo da migração não compensa.
- Limitações: novos projetos (a comunidade se movimentou), velocidade de features (o ritmo de desenvolvimento desacelerou após a aquisição).
A árvore de decisão — escolha pelo tamanho da build e estrutura do time
Site de conteúdo moderno com menos de 10K páginas, time confortável com JavaScript
Astro. O padrão. Use a Content Layer API para qualquer fonte de conteúdo, Server Islands para conteúdo dinâmico ocasional, e o ecossistema de integrações para tudo mais. Este é o caso de 80% em 2026.
Site com mais de 20K páginas e deploys diários
Hugo se seu time está confortável com Go templates. HostList em 91K páginas no Astro constrói em 18 minutos; o mesmo site no Hugo construiria em 2-3 minutos. Nessa escala, a economia do Hugo fica significativamente melhor para custo de 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.
Blog ou site de documentação, avesso a configurações
Eleventy. Baseado em JavaScript, configuração mínima, saída HTML limpa. Exatamente para quando 'eu só quero HTML' é o briefing.
Hospedagem gratuita no GitHub Pages necessária
Jekyll. A única categoria onde ainda é o padrão em 2026 — suporte nativo no GitHub Pages significa zero infraestrutura de hospedagem para manter.
Site Gatsby existente
Mantenha-se no Gatsby a menos que a migração seja genuinamente necessária. Migrar Gatsby para Astro é realista em 4-8 semanas para um site de tamanho típico, mas o custo de migração raramente compensa para sites em produção que estão funcionando.
Benchmarks de tempo de build — medidos, não alegados
Ancorado a um site de conteúdo hipotético com 5.000 páginas, otimização de imagem habilitada, implantado em um executor de CI típico.
- Hugo: 30-60 segundos para o build completo. Processamento de imagem feito em paralelo. Genuinamente o mais rápido da categoria.
- Eleventy: 1-3 minutos. Baseado em JavaScript, mas com overhead mínimo.
- Astro: 4-7 minutos. O pipeline de otimização de imagem e a etapa de build do Content Layer são as partes pesadas.
- Jekyll: 3-8 minutos. Mais lento que Eleventy, mais rápido que Gatsby, o overhead do Ruby é notável.
- Gatsby: 8-15 minutos. A camada de dados GraphQL adiciona tempo real nessa escala.
Com 50K páginas, o gap se amplia dramaticamente. Hugo em ~3-5 minutos; Astro em ~25-40 minutos; Gatsby passa de 60 minutos. Para sites em produção com frequência de deploy diária ou mais, essa é a diferença entre um CI loop útil e um que se torna o gargalo.
FAQ
Astro é melhor que Hugo?
Para sites de conteúdo moderno com times orientados a JavaScript, sim — o modelo de componentes do Astro, Content Layer API e seu ecossistema de integrações são muito mais úteis que o templating Go do Hugo para o projeto web típico de 2026. Para sites com mais de 20K páginas onde o tempo de build é um custo real, Hugo vence em velocidade bruta de build por 5-10x. A escolha depende do time e da escala; ambos são legitimamente a resposta correta para diferentes briefs.
Devo migrar de Gatsby para Astro?
Apenas se o site Gatsby está causando problemas reais — builds lentos, complexidade GraphQL que o time não consegue manter, dependency drift que se torna uma preocupação de segurança. Para sites Gatsby que estão funcionando, o custo de migração de 4-8 semanas raramente vale a pena. A comunidade Gatsby avançou, mas o framework ainda é estável em produção.
Por que Hugo é muito mais rápido que Astro?
Hugo é escrito em Go, compila para um binário único e usa o templating engine do Go que é otimizado para geração de texto estático. Astro é baseado em JavaScript, roda através de Node e usa os renderers React/Vue/Svelte conforme necessário. A diferença fundamental de arquitetura é real e não está fechando — Astro não alcançará Hugo em velocidade de build porque as linguagens são diferentes. A resposta do Astro é 'bom o suficiente para a maioria dos sites'; Hugo é 'significativamente mais rápido quando importa'.
O Eleventy ainda é relevante em 2026?
Sim, para engenheiros que especificamente querem um SSG JavaScript com pouca configuração, sem o modelo de componentes do Astro. Eleventy é mais 'apenas me dê HTML' do que o Astro é, e essa simplicidade é genuinamente valorizada por alguns times. Para a maioria dos sites de conteúdo modernos, Astro é o padrão mais poderoso; para sites no formato blog onde a simplicidade é o objetivo explícito, Eleventy ainda vence.
Posso usar Jekyll fora do GitHub Pages?
Tecnicamente sim — Jekyll roda em qualquer host com capacidade Ruby. Praticamente raro em 2026. Se você não está fazendo deploy para o GitHub Pages, o equivalente moderno é Astro no Cloudflare Pages ou no free tier do Netlify, que te dá um build mais rápido, uma toolchain mais moderna, e a mesma história de hosting gratuito.
Leitura relacionada
Next.js vs Remix vs Astro em 2026 — a comparação de frameworks quando a escolha se expande além de SSGs puros. — the framework comparison when the choice expands beyond pure SSGs.
Web Frameworks Hub — a árvore de decisão mais ampla de framework, com contexto de SSG. — the broader framework decision tree, with SSG context.
Headless WordPress + Astro: um setup funcionando — setup prático se sua escolha de SSG é Astro combinado com um CMS. — practical setup if your SSG choice is Astro paired with a CMS.
Como construí um diretório de 25.000 páginas em Next.js — estudo de caso de produção em escala; útil para o contexto de decisão SSG-vs-Next.js. — production case study at scale; useful for SSG-vs-Next.js decision context.
A escolha de SSG é uma decisão de tempo de build e formato de time, não uma decisão de features. Escolha pelo o que seu time vai realmente manter pelos próximos dois anos.
Agende uma chamada SSG pick de 30 minutos — descreva a estrutura do site, o time, a frequência de build, o alvo de deploy. Saia com uma decisão Astro-vs-Hugo-vs-Eleventy que se encaixa no briefing. — 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.