Melhor gerador de site estático: Astro, Hugo, Eleventy ou Next.js

Um gerador de site estático pega os seus textos (em geral Markdown), aplica templates e produz uma pasta de arquivos HTML, CSS e JavaScript prontos para servir. Não há banco nem servidor de aplicação no caminho de cada visita, o que deixa o site rápido, barato e difícil de derrubar. Se o conceito ainda é novo, comece por o que é um site estático.

A dúvida costuma ser qual gerador usar. Quatro nomes aparecem em quase toda lista: Astro, Hugo, Eleventy e Next.js. Os quatro geram bons sites, mas partem de filosofias diferentes, e a escolha errada aparece meses depois, quando o build fica lento ou o site carrega JavaScript demais.

Quais critérios importam na escolha?#

1. Quanto JavaScript vai para o navegador. Um blog não precisa de framework rodando no cliente. Menos JavaScript significa carregamento mais rápido, principalmente no celular.
2. Quantidade de páginas e tempo de build. Com dezenas de páginas, qualquer gerador serve. Com milhares, o tempo de build passa a pesar no dia a dia.
3. Interatividade. Um formulário de busca ou um carrossel é uma coisa; um painel com estado complexo é outra.
4. Linguagem e ecossistema. Se você já usa React, aproveitar componentes conta muito. Se não quer depender de Node.js, isso também elimina opções.
5. Chance de precisar de servidor depois. Login, conteúdo personalizado ou páginas geradas sob demanda pedem renderização no servidor. A diferença entre os modelos está em SSR, SSG e site estático.

Quando o Astro é a melhor escolha?#

Astro é um framework para sites de conteúdo. Por padrão, as páginas são pré-renderizadas no build como HTML estático, e o Astro remove todo o JavaScript do cliente automaticamente. Quando uma parte precisa de interatividade, você marca só aquele componente com uma diretiva como client:load, client:idle ou client:visible, e ele vira uma "ilha" com o seu próprio JavaScript. As ilhas podem ser escritas em React, Preact, Svelte, Vue ou SolidJS, até misturadas na mesma página. O Astro exige uma versão recente do Node.js; o mínimo está na documentação de instalação.

Uma página .astro mistura um bloco de código que roda no build com o HTML de saída:

---
const posts = [
  { slug: "ola-mundo", title: "Olá, mundo" },
  { slug: "segundo-post", title: "Segundo post" },
];
---

<html lang="pt-br">
  <head>
    <meta charset="utf-8" />
    <title>Meu blog</title>
  </head>
  <body>
    <h1>Meu blog</h1>
    <ul>
      {posts.map((p) => <li><a href={`/blog/${p.slug}/`}>{p.title}</a></li>)}
    </ul>
  </body>
</html>

Num teste, o astro build dessa página gerou um dist/index.html sem nenhuma tag <script>.

Prós: zero JavaScript por padrão, ilhas com o framework que você preferir, coleções de conteúdo em Markdown e MDX, e a opção de renderizar páginas sob demanda com um adaptador, se o site crescer.

Contras: o ecossistema muda rápido. Versões maiores costumam trocar peças internas, como a versão do Vite, o compilador ou o processador de Markdown padrão, e plugins de remark e rehype podem passar a exigir configuração extra. Atualizar entre versões maiores pede leitura do guia de migração.

Quando o Hugo é a melhor escolha?#

Hugo é um gerador escrito em Go, otimizado para velocidade: segundo a documentação, ele renderiza um site completo em segundos, muitas vezes menos. É distribuído como um executável pronto e não precisa de Node.js.

hugo new project meu-site
cd meu-site
hugo server   # servidor local com recarga automática
hugo          # build de produção na pasta public/

Nas versões recentes, o comando de criação é hugo new project (tutoriais antigos usam hugo new site).

Prós: builds muito rápidos mesmo com milhares de páginas, nada de node_modules, taxonomias (tags, categorias) e multilíngue embutidos, temas prontos.

Contras: os templates usam a sintaxe de templates do Go, que tem curva de aprendizado própria para quem vem de JavaScript. Componentes interativos ficam por sua conta, em JavaScript avulso. O LibSass embutido na edição extended foi descontinuado na versão 0.153.0, e para Sass a recomendação passou a ser o Dart Sass.

Quando o Eleventy é a melhor escolha?#

Eleventy (ou 11ty) é um gerador minimalista em Node.js. Ele transforma templates em páginas e aceita muitas linguagens: HTML, Markdown, JavaScript, WebC, Nunjucks, Liquid, Handlebars, Pug e outras. Ele roda em qualquer versão recente do Node.js. Ele não impõe framework de front-end nem pipeline de assets: o HTML que você escreve é o HTML que sai.

Uma configuração mínima em ES modules ("type": "module" no package.json):

// eleventy.config.js
export default function (eleventyConfig) {
  eleventyConfig.addPassthroughCopy("src/img"); // copia as imagens sem processar
}

export const config = {
  dir: { input: "src", output: "_site" },
};

Com um src/index.md e npx @11ty/eleventy, o resultado vai para _site/. Num teste, o build de uma página levou menos de meio segundo.

Prós: simples de entender, sem JavaScript no cliente a não ser o que você colocar, flexível com templates, ótimo para blogs e documentação.

Contras: sem componentes interativos prontos nem pipeline de imagens e CSS por padrão (existem plugins oficiais para imagem). Projetos grandes exigem que você organize a estrutura sozinho.

Quando o Next.js faz sentido para um site estático?#

Next.js é um framework React completo, com renderização no servidor. Ele também exporta um site estático: com output: "export" no next.config, o next build gera uma pasta out/ que qualquer servidor de arquivos consegue servir.

// next.config.mjs
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  trailingSlash: true, // gera /sobre/index.html em vez de /sobre.html
  images: { unoptimized: true }, // sem o servidor do Next.js, não há otimização de imagem sob demanda
};

export default nextConfig;

A documentação lista o que deixa de funcionar na exportação estática: rotas dinâmicas sem generateStaticParams(), cookies, rewrites, redirects, headers, proxy, ISR, Server Actions, draft mode e a otimização de imagem com o loader padrão.

Prós: se o time já usa React e Next.js, reaproveita componentes e conhecimento. Dá para começar estático e migrar para um servidor depois sem trocar de framework.

Contras: carrega o runtime do React em toda página. Num teste, uma exportação com uma página que só dizia "Olá" referenciava mais de 100 KB de JavaScript comprimido (gzip). Para um blog, é peso sem retorno. Para hospedar a versão com servidor, veja como hospedar uma aplicação Next.js.

Como os quatro se comparam lado a lado?#

Qual escolher em cada cenário?#

Na dúvida, Astro é a escolha mais versátil para um site novo de conteúdo. Se o site é só texto e você quer o mínimo de peças, Eleventy. Se o volume de páginas é o problema, Hugo. Antes de decidir onde publicar, vale comparar quanto custa hospedar um site estático. E se o seu site virar uma SPA com rotas no cliente, fique atento ao erro 404 ao recarregar, que exige configurar o servidor.

Como fazer isso na Square Cloud#

A Square Cloud tem um runtime de sites estáticos, além de runtimes de Node.js e outras linguagens. Você roda o build do gerador (Astro, Hugo, Eleventy ou Next.js com exportação) e faz o deploy da pasta de saída por upload de ZIP, CLI ou GitHub. A plataforma não roda etapa de build: gere a pasta na sua máquina ou num CI externo, como o GitHub Actions, e envie o resultado.

Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS, e o tráfego passa por uma CDN global, com TLS automático e tráfego ilimitado (política de uso justo). Domínio personalizado começa no plano Standard: você cria os registros DNS no seu registrador, e o domínio continua registrado em seu nome. O analytics web sem cookies, coletado no servidor, vem em todo plano e mostra visitas, rotas, países e códigos de status.

Os planos são pagos, a partir de R$ 12,49 por mês no Hobby, e uma aplicação web usa no mínimo 512 MB do pool de RAM do plano. Veja a hospedagem de sites.