Melhores geradores de sites estáticos em 2026: Astro a Hugo

Para a maioria dos novos sites institucionais e blogs em 2026, Astro é a escolha padrão: foco em conteúdo, zero JavaScript a menos que você opte por ele, e adapters para qualquer hospedagem. Escolha Next.js static export quando o time já investiu em React e pode precisar de recursos de servidor mais tarde, e Hugo quando velocidade bruta de build em milhares de páginas importa mais do que um ecossistema JavaScript. O Jekyll continua ok para sites pequenos no GitHub Pages, e o Gatsby não deve ser usado em nada novo.

O que mudou nos geradores de sites estáticos desde a era Jekyll vs Hugo vs Gatsby

A comparação original entre os três assumia um trade-off: builds rápidos com uma linguagem de template rígida (Hugo, Jekyll), ou um modelo moderno de componentes pago com builds lentos e JavaScript pesado no cliente (Gatsby). Esse trade-off não existe mais.

Três coisas moveram o mercado:

• Arquitetura de islands. O Astro popularizou renderizar a página como HTML estático e hidratar só os componentes que precisam de JavaScript. Uma página institucional sai com zero JS por padrão; o formulário de newsletter ou o toggle de preços hidrata sozinho. Isso eliminou o principal custo do Gatsby sem abrir mão de componentes React, Vue, Svelte ou Solid.
• Vite como toolchain compartilhada. Astro, VitePress, Docusaurus (nas versões recentes) e a maior parte do mundo Vue e Svelte são construídos sobre o Vite. A inicialização do dev server caiu de dezenas de segundos para bem menos de um segundo, e os plugins valem entre ferramentas. Veja Vite vs Webpack vs Parcel para o lado das ferramentas de build dessa mudança.
• Frameworks full-stack que também exportam estático. Next.js, Nuxt e SvelteKit suportam pré-renderizar tudo em arquivos simples. Um time pode começar estático e ligar a renderização no servidor para uma rota depois, sem trocar de framework.

O resultado é que "gerador de sites estáticos" hoje descreve mais um modo de saída do que uma categoria de ferramenta. A pergunta deixou de ser "qual SSG" e virou "qual modelo de conteúdo e qual estratégia de hidratação", com hospedagem em CDN como constante. O post sobre arquitetura Jamstack cobre o lado de hospedagem e APIs com mais profundidade.

Tabela comparativa de geradores de sites estáticos (2026)

	Astro	Next.js (static export)	Hugo	Eleventy	Jekyll	Gatsby	Docusaurus	VitePress
Linguagem / runtime	TypeScript, Node (Vite)	TypeScript, Node	Go, binário único	JavaScript, Node	Ruby	JavaScript, Node (webpack)	TypeScript, Node, React	TypeScript, Node (Vite), Vue
Velocidade de build (ordem de grandeza)	Dezenas de segundos para centenas de páginas; cresce com o trabalho de imagens	Dezenas de segundos a minutos; memoize os data loaders	Segundos para milhares de páginas	Segundos a um minuto para milhares de páginas	Segundos a minutos; fica lento com plugins	Minutos; precisa de builds incrementais	Dezenas de segundos a minutos	Segundos a dezenas de segundos
Modelo de conteúdo	Markdown/MDX com content collections tipadas; qualquer CMS via loaders	O que você codificar; Markdown via bibliotecas, CMS via fetch	Markdown, front matter, arquivos de dados, taxonomias	Markdown, Nunjucks/Liquid, dados globais, qualquer fonte de dados JS	Markdown, Liquid, collections	Camada de dados GraphQL sobre source plugins	Docs em Markdown/MDX, blog, versionamento	Markdown com Vue dentro do Markdown
Islands / hidratação parcial	Sim, nativo (diretivas client:*)	Sem islands; React Server Components reduzem o JS no cliente	Nenhuma (sem JS por padrão)	Nenhuma (sem JS por padrão)	Nenhuma	Não, hidratação completa	Não, hidratação completa (React)	Hidratação Vue por página
i18n	Roteamento, fallbacks e content collections por locale nativos	Não suportado pelo roteamento do static export; feito à mão com segmento [locale] e uma biblioteca	Nativo, maduro, árvores de conteúdo por idioma	Plugin (@11ty/eleventy-i18n) mais sua própria estrutura	Plugin (jekyll-polyglot), limitado	Plugins, irregular	Nativo, com docs traduzidas por versão	Nativo, via configuração
Tratamento de imagens	<Image> e <Picture> nativos, otimização em build	next/image exige unoptimized: true no export; use um loader ou pré-processe	Processamento de imagens nativo nos templates	Plugin (@11ty/eleventy-img), muito capaz	Plugins, fraco	Plugin (gatsby-plugin-image), bom mas lento	Manual, ou plugin	Manual; pipeline de assets do Vite
Saúde do ecossistema	Crescendo rápido, releases frequentes	Muito grande; o modo export é um subconjunto	Estável, maduro, ritmo de features mais lento	Saudável, core team pequeno, bom conjunto de plugins	Mantido, pouca atividade	Modo manutenção após a aquisição pela Netlify	Ativo, apoiado pela Meta	Ativo, mantido pelo time do Vue
Melhor encaixe	Sites institucionais, blogs, sites de conteúdo com alguma interatividade	Times React; sites que podem virar aplicações	Grandes volumes de conteúdo, docs, sites multilíngues, CI sem Node	Blogs e sites onde você quer controle total e mínimo de mágica	Sites pequenos no GitHub Pages	Só sites legados	Docs de produto e API, versionadas	Docs de bibliotecas e ferramentas internas

Os números de build são ordens de grandeza. Meça com o seu próprio conteúdo antes de decidir; processamento de imagens e busca de dados dominam o tempo de build muito mais do que a engine de templates do gerador.

Astro: o padrão com foco em conteúdo

O Astro renderiza componentes .astro em HTML no build e remove todo o JavaScript, a menos que um componente carregue uma diretiva client:load, client:idle ou client:visible. Você pode colocar componentes React, Vue, Svelte, Solid ou Preact lado a lado, o que faz dele a escolha de menor risco quando o time tem habilidades de front-end mistas.

As content collections dão a Markdown e MDX um schema tipado:

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = { blog };

Um campo faltando quebra o build em vez de produzir uma página em branco. Os loaders também puxam de um CMS headless ou de uma API com a mesma interface, então trocar Markdown local por um CMS não mexe nos seus templates. Veja CMS headless vs tradicional para saber como tomar essa decisão.

Onde o Astro fica devendo: sites muito grandes (dezenas de milhares de páginas) buildam mais devagar que o Hugo, e se você precisa de um shell de aplicação de verdade, com roteamento no cliente em todo lugar, um framework completo encaixa melhor. O Astro também suporta renderização no servidor via adapters, então a saída de emergência existe.

Next.js static export: para times React que podem precisar de mais depois

O Next.js com output: 'export' no next.config grava HTML, CSS e JS puros em uma pasta de saída que qualquer CDN consegue servir.

O ponto importante é o que o static export desliga: middleware, API routes, server actions, Incremental Static Regeneration, revalidação sob demanda, otimização de imagens (defina images.unoptimized: true) e o roteamento i18n nativo. Toda rota dinâmica precisa de generateStaticParams. Se você depende de qualquer um desses, já não está construindo um site estático e deveria hospedar em um runtime Node ou edge.

Duas regras práticas de quem roda Next.js export com algumas centenas de páginas:

• Memoize os data loaders. generateStaticParams, generateMetadata e o componente da página chamam o seu loader de conteúdo para cada página. Sem cache, algumas centenas de páginas podem disparar dezenas de milhares de leituras de arquivo e transformar um build de 30 segundos em vários minutos.
• Ative trailingSlash: true e linke com a barra. Hosts estáticos servem /about/index.html; um link para /about gera um redirect que os crawlers indexam no lugar da página. Isso importa para Core Web Vitals e SEO técnico.

Escolha Next.js export quando compartilha componentes com uma aplicação React, quando a memória muscular do time é React, ou quando quer um caminho crível para renderização no servidor. Escolha Astro quando o site é conteúdo e a dependência de React não compra nada.

Hugo e Eleventy: builds sem JavaScript que escalam

O Hugo é um binário único em Go. Instale, rode hugo, e milhares de páginas Markdown viram HTML em segundos. Não há node_modules, então o CI é um download e um único comando. Suporte multilíngue faz parte do modelo de conteúdo (uma árvore de diretórios por idioma, ou um sufixo de idioma por arquivo), taxonomias são nativas e o processamento de imagens roda nos templates. Os templates em Go são o principal custo de aprendizado: concisos, estranhos para desenvolvedores JavaScript e desagradáveis de depurar. O Hugo é a melhor escolha quando o volume de conteúdo é grande, o time não quer uma toolchain JavaScript, ou você precisa de roteamento multilíngue sem plugins.

O Eleventy (11ty) adota a postura oposta: core mínimo, configuração em JavaScript e a linguagem de template que você escolher (Nunjucks, Liquid, WebC, JS puro). Ele não tem opinião sobre JavaScript no cliente, o que significa que a saída padrão é zero JS. Os dados podem vir de qualquer lugar que uma função JavaScript alcance. O plugin de imagens é um dos melhores da categoria. O Eleventy é a escolha certa quando você quer a filosofia de saída do Hugo com um ecossistema JavaScript e controle total sobre cada etapa. O trade-off: sem roteamento i18n nativo nem schema de conteúdo tipado.

Um build mínimo com Eleventy:

npm install @11ty/eleventy
npx @11ty/eleventy --serve

Jekyll e Gatsby: o que fazer com eles em 2026

O Jekyll ainda é publicado, ainda roda o GitHub Pages e ainda funciona para um site pessoal ou uma página de projeto pequena com um punhado de arquivos Markdown. Seus problemas são práticos: a toolchain Ruby diverge entre máquinas, há uma allowlist de plugins no GitHub Pages, os builds ficam lentos com muitos plugins e o conjunto de temas ativos é bem menor. Escolha Jekyll só quando a hospedagem sem configuração do GitHub Pages for o ponto central. Caso contrário, comece no Eleventy, que aceita templates Liquid e front matter no estilo Jekyll e torna a mudança suave.

O Gatsby foi a primeira ferramenta a combinar React, uma camada de dados GraphQL e otimização de imagens em um único pacote, e mereceu a popularidade que teve por volta de 2019. Depois, duas coisas aconteceram. O React migrou para Server Components e um modelo de "menos JavaScript no cliente" que a arquitetura de hidratação completa do Gatsby não conseguiria adotar sem uma reescrita. E depois que a Netlify adquiriu a Gatsby Inc., o framework passou a uma cadência de manutenção: correções saem, mas o ecossistema de source plugins, o produto de build na nuvem e a documentação pararam de acompanhar. Um time que escolhe Gatsby hoje herda um build baseado em webpack, uma camada GraphQL que poucos querem manter e tempos de build longos sem os builds incrementais que só o descontinuado Gatsby Cloud tratava bem.

Docusaurus e VitePress: sites de documentação

Documentação tem requisitos que as ferramentas de uso geral atendem mal: docs versionadas, sidebars geradas a partir da árvore de arquivos, busca, páginas de referência de API e docs traduzidas que acompanham as versões.

O Docusaurus cobre tudo isso de fábrica. É baseado em React, suporta MDX, traz versionamento e i18n como recursos centrais e tem plugins para referências OpenAPI e busca. O custo é um build mais pesado, hidratação completa em React e mais configuração.

O VitePress é menor e mais rápido. É baseado em Vue, construído sobre o Vite, e produz um site de docs limpo com sidebar, busca e modo escuro a partir de um único arquivo de configuração. Não faz versionamento nativamente, então serve para documentação de bibliotecas, docs internas de engenharia e produtos de versão única.

O Astro Starlight é a terceira opção: um tema de docs sobre o Astro com i18n, sidebars e busca. Se o resto dos seus sites é Astro, o Starlight evita rodar um segundo framework.

Migrando do Jekyll ou do Gatsby

Conteúdo em Markdown com front matter é portável. O trabalho está nas URLs, nas imagens e nos templates.

Do Jekyll:

1. Exporte as pastas _posts e _pages como estão. As chaves do front matter (title, date, layout, permalink) mapeiam diretamente para content collections do Astro ou dados do Eleventy.
2. Reescreva os templates Liquid. O Eleventy aceita Liquid nativamente, então o tema pode migrar com mudanças mínimas. O Astro exige reescrever os layouts em .astro, o que costuma levar um ou dois dias para um blog típico.
3. Preserve os permalinks. O padrão /:year/:month/:day/:title/ do Jekyll precisa ser reproduzido ou redirecionado. Gere um mapa de redirects (_redirects no Cloudflare Pages ou Netlify) a partir do sitemap antigo antes de trocar o DNS.
4. Tire o processamento de imagens dos plugins Ruby e leve para o pipeline de imagens do gerador.

Do Gatsby:

1. Remova a camada GraphQL primeiro. As chamadas useStaticQuery do Gatsby viram imports diretos ou consultas às content collections. Essa é a maior parte do trabalho.
2. Componentes React portam para o Next.js sem mudanças e para o Astro com uma diretiva client:* onde precisam hidratar; a maioria não vai precisar.
3. Substitua gatsby-plugin-image por next/image (com unoptimized e uma etapa de pré-processamento) ou pelo <Image> do Astro.
4. Substitua os plugins gatsby-source-* por chamadas fetch em um loader. Contentful, Sanity e CMSs parecidos têm SDKs simples.
5. Audite gatsby-browser.js e gatsby-ssr.js em busca de wrappers globais; eles viram um layout raiz.

Nos dois casos, compare o HTML gerado para uma amostra de páginas e rastreie o novo build em busca de 404s antes da virada. Mantenha os redirects do sitemap antigo por pelo menos alguns meses.

Checklist de decisão por tipo de projeto

Use a primeira linha que corresponder.

• Site institucional com CMS e alguns componentes interativos. Astro. Use islands para as partes interativas e um loader de CMS para o conteúdo. Next.js export se o site compartilha uma biblioteca de componentes com uma aplicação React.
• Documentação de produto ou API, versionada. Docusaurus. Versão única, time que curte Vue ou docs internas: VitePress. Já em Astro: Starlight.
• Blog ou site editorial com centenas de posts. Astro ou Eleventy. Acima de cerca de dez mil páginas, ou sem permissão para toolchain JavaScript no CI: Hugo.
• Loja de e-commerce. Um gerador estático dá conta do catálogo e das landing pages; carrinho, checkout e conta precisam de código no cliente ou de um servidor. Next.js (geralmente fora do modo export) ou Astro com rotas renderizadas no servidor. Puramente estático só é viável com uma API de commerce headless e carrinho no cliente.
• Site multilíngue. Astro (roteamento i18n e fallbacks nativos) ou Hugo (árvores de conteúdo por idioma maduras). Evite Next.js export a menos que esteja preparado para construir o roteamento de locale por conta própria; o i18n do framework não funciona no modo export. O post sobre i18n e localização cobre as decisões do lado do conteúdo.
• Site pessoal ou de projeto pequeno no GitHub Pages, sem etapa de build. Jekyll ainda é aceitável. Qualquer coisa com planos de crescimento: Eleventy.
• Site Gatsby existente. Planeje a migração; não adicione features.

Recomendação

Adote Astro como padrão para novos sites de conteúdo. Ele entrega o mínimo de JavaScript, suas content collections pegam erros no build e permite usar o framework de componentes que o seu time já conhece. Vá para Next.js static export só quando React já for o padrão da empresa e você espera que o site ganhe recursos de aplicação. Escolha Hugo para conteúdos grandes ou multilíngues, onde um binário Go no CI é uma vantagem, não uma restrição. Use Docusaurus ou VitePress para documentação em vez de forçar uma ferramenta de uso geral. Mantenha o Jekyll para o caso pequeno no GitHub Pages e trate o Gatsby como origem de migração, não como destino. Na Arvucore, costumamos recomendar Astro ou Next.js export para sites institucionais de clientes, e rodamos este site em Next.js static export exatamente pelo motivo de compartilhar React citado acima.