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 essencial: Astro é o padrão moderno para sites de conteúdo, Hugo vence em puro speed de build, Eleventy vence em simplicidade config-light, e Gatsby está em declínio suave; escolha pelo time e modelo de conteúdo.
O quadro honesto de 2026: Astro venceu o segmento 'moderno' de forma definitiva, Hugo venceu o segmento 'rápido e agnóstico de linguagem' de forma definitiva, Eleventy é a resposta certa para o nicho dos curiosos-por-JavaScript-mas-avessos-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 hub de frameworks cobre a decisão mais ampla de framework; este post é especificamente sobre o subconjunto dos geradores de site estático.
Os cinco SSGs em 60 segundos
- Astro, modelo de componentes 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 de tempo de build enviado ao cliente. A escolha certa para engenheiros que querem familiaridade com JS sem overhead de React ou Vue.
- Hugo é baseado em Go e evita um pipeline de build Node. Vale a pena testar quando o tempo de build do site completo domina o ciclo de lançamento. Compare-o em seu próprio conteúdo e carga de trabalho de imagem em vez de assumir um multiplicador de velocidade universal.
- Jekyll, baseado em Ruby, nativo para GitHub Pages, ecossistema de templates maduro. Usado principalmente para projetos legados e hospedagem gratuita em GitHub Pages em 2026.
- Gatsby, baseado em React com camada de dados GraphQL, em declínio suave desde a aquisição pela Netlify em 2023. Ainda estável em 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 é uma escolha padrão forte para sites de conteúdo que precisam de templates de componentes e interatividade seletiva. HostList.io é um exemplo de produção com aproximadamente 91.000 páginas. Seu último rebuild completo citado foi em torno de 18 minutos, mas esse é um site configuration, não um benchmark portável de framework. A escolha depende de fontes de conteúdo, trabalho com imagens, frequência de implantação e habilidades da equipe.
- 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: equipes que não querem um pipeline de build JavaScript e rebuilds completos que excedem o orçamento de implantação do projeto. Meça o site real antes de atribuir um build lento ao Astro em si.
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 vale a pena testar quando o tempo de build é o gargalo. Uma comparação Astro-para-Hugo só é significativa com o mesmo conteúdo, transformações de imagem, runner, estado do cache e requisitos de saída. Um timing genérico de 5.000 páginas não pode estabelecer o resultado do seu projeto.
- 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 aquém em: a maioria das necessidades modernas, builds mais lentos que Hugo, ferramentas mais datadas 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 escolhendo Gatsby em números significativos. A camada de dados GraphQL que era o diferencial do Gatsby em 2018 agora é amplamente considerada excessiva 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. Escolha certa apenas quando você já tem um site Gatsby e migrar não vale a pena.
- 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 do build e forma 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
Compare a rebuild completo do Hugo com o Astro se as reconstruções completas no Astro estão atrasando os lançamentos diários. O rebuild do Astro citado pela HostList foi em torno de 18 minutos com aproximadamente 91.000 páginas; é necessário um build equivalente desse site em Hugo antes de prever a diferença de velocidade.
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 em que ainda é o padrão em 2026, o suporte nativo do GitHub Pages significa zero infraestrutura de hospedagem para manter.
Site Gatsby existente
Mantenha-se no Gatsby a menos que a migração resolva um problema concreto. Estime o esforço a partir do seu modelo de conteúdo, rotas, integrações e design system; uma estimativa genérica de quatro a oito semanas não é confiável para todos os sites de produção.
Como comparar o tempo de build do seu site
Os números anteriores nesta seção foram intervalos ilustrativos para um site hipotético de 5.000 páginas, não medições de implementações idênticas. Para tomar uma decisão real de plataforma, crie o mesmo conteúdo representativo e imagens no mesmo runner de CI, com cache frio e cache quente.
- Registre o tempo total de build, pico de memória, tempo de processamento de imagens, tamanho de saída e o número de páginas regeneradas após uma edição. O pipeline de conteúdo rápido do Hugo pode ajudar, mas o trabalho com imagens e a implantação ainda podem dominar.
- O resultado do Eleventy depende de templates, plugins e de como o conteúdo é carregado. Inclua a stack de plugins real no teste.
- O build de componentes, carregamento de conteúdo e pipeline de imagens do Astro afetam reconstruções completas. Meça o build de produção em vez de extrapolar a partir de um projeto inicial.
- O resultado do Jekyll depende de plugins Ruby, collections e configurações de build incremental. A compatibilidade com GitHub Pages pode superar uma diferença de tempo de build para um site pequeno.
- O Gatsby pode gastar tempo substancial em seu pipeline de dados e imagens. Faça benchmark do projeto existente antes de agendar uma migração apenas para melhorar o CI.
Com dezenas de milhares de páginas, teste a atualização de conteúdo que acontece com mais frequência, não apenas um build completo limpo. Um build completo mais lento pode ser aceitável com caching ou publicação seletiva; um build local rápido ainda pode ser implantado lentamente quando a saída é muito grande.
Para detalhes de implementação, use a documentação do Astro e as orientações de build de cada gerador. Mantenha o script de benchmark e as configurações do runner com a comparação publicada para que outra equipe possa reproduzir o resultado.
FAQ
O Astro costuma ser a melhor opção para uma equipe JavaScript que constrói um site de conteúdo orientado por componentes. O Hugo vale a pena testar quando o tempo de build, uma equipe orientada por Go ou um pipeline de conteúdo mais simples impulsiona a decisão. Compare ambos usando a mesma carga de trabalho representativa.
O Astro costuma ser a melhor opção para uma equipe JavaScript que constrói um site de conteúdo orientado por componentes. O Hugo vale a pena testar quando o tempo de build, uma equipe orientada por Go ou um pipeline de conteúdo mais simples impulsiona a decisão. A afirmação anterior de velocidade cinco a dez vezes maior não era uma medição de site equivalente.
Devo migrar de Gatsby para Astro?
Apenas se o site Gatsby está causando problemas reais: builds lentos, complexidade da camada de dados ou drift de dependências que a equipe não consegue manter. Estime a migração em relação a esse custo. Um site Gatsby de produção que funciona bem pode ser melhor deixado como está.
Por que Hugo é muito mais rápido que Astro?
Hugo é escrito em Go, compila para um único binário e usa o motor de templating do Go que é otimizado para geração de texto estático. Astro é baseado em JavaScript, roda através de Node e usa os renderizadores React/Vue/Svelte conforme necessário. A diferença de arquitetura fundamental é real e não está fechando, Astro não vai 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?
Sim. O Jekyll é executado em qualquer host capaz de Ruby. O GitHub Pages é seu caminho mais fácil; o Astro no Cloudflare Pages ou Netlify é outra opção, mas verifique o plano de host atual e a economia de build antes de assumir a mesma capacidade gratuita.
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.
Web Frameworks Hub, a árvore ampla de decisão de frameworks, com contexto SSG.
Headless WordPress + Astro: uma configuração funcional, setup prático se sua escolha SSG for Astro pareado com um CMS.
Como construí um diretório de 25.000 páginas em Next.js, estudo de caso em produção em escala; útil para contexto de decisão SSG-vs-Next.js.
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 call de 30 minutos para escolher SSG, descreva a forma 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 escopo.