Astro ou Next.js: arquitetura e desempenho comparados

Astro e Next.js aparecem lado a lado em quase toda discussão sobre como construir um site moderno com JavaScript. Os dois geram HTML no servidor, usam rotas baseadas em arquivos e aceitam componentes React. Por isso parecem intercambiáveis.

Não são. Eles partem de perguntas diferentes. O Astro pergunta “quanto JavaScript esta página realmente precisa?”. O Next.js pergunta “como entregar uma aplicação React rápida, com partes no servidor e partes no navegador?”.

Este texto compara a arquitetura e o desempenho dos dois com base na documentação oficial (Astro 7 e Next.js 16.4, consultadas em 8 de outubro de 2026) e em dados públicos do HTTP Archive. Transparência: o site do Token & Tech é construído com Astro. Por isso, mostramos com o mesmo cuidado os casos em que o Next.js é a escolha melhor.

Duas premissas diferentes

A página Why Astro? apresenta o Astro como um framework para sites guiados por conteúdo, que prefere renderizar no servidor e envia zero JavaScript por padrão.

O Next.js é um framework para aplicações React. O guia do Astro de migração a partir do Next.js resume a diferença: o Next.js é tratado como uma aplicação React de página única, enquanto o Astro é um site de várias páginas.

Uma aplicação de página única (SPA, na sigla em inglês) carrega uma vez e troca o conteúdo da tela pelo JavaScript, sem recarregar o documento. Um site de várias páginas (MPA) entrega um documento HTML novo a cada link clicado. As duas abordagens têm méritos, e boa parte das diferenças a seguir vem dessa escolha de partida.

Como cada um renderiza uma página

No Astro, a página é HTML montado no build ou no servidor. A documentação sobre ilhas explica que o JavaScript de cliente é removido de todos os componentes, a não ser que você adicione uma diretiva como client:load ou client:visible. Cada ilha carrega de forma independente. As ilhas de servidor (server:defer) permitem renderizar um trecho personalizado depois do resto da página.

No Next.js, com o App Router, páginas e layouts são Server Components por padrão, segundo a página Server and Client Components. Eles rodam no servidor e podem buscar dados direto da fonte. Quando você precisa de estado, eventos ou APIs do navegador, marca o arquivo com "use client" e ele vira um Client Component.

A documentação descreve o que chega ao navegador no primeiro acesso:

1. O HTML, para mostrar uma prévia rápida e ainda não interativa.
2. O RSC Payload, uma representação compacta da árvore de componentes de servidor, usada pelo React para conciliar as duas árvores.
3. O JavaScript que faz a hidratação dos Client Components, ou seja, que liga os eventos ao HTML para torná-lo interativo.

Há uma regra que pesa no tamanho final. Segundo a mesma página, quando um arquivo recebe "use client", todos os seus imports e os componentes que ele renderiza diretamente entram no pacote de JavaScript do cliente. A recomendação oficial é marcar só os componentes interativos, e não grandes partes da interface.

Na avaliação da redação, os dois modelos convergiram: ambos renderizam no servidor e isolam o que é interativo. A diferença está no ponto de partida. No Astro, o padrão é nenhuma interatividade, e você adiciona ilhas. No Next.js, a página é uma árvore React, e o próprio React e o roteador fazem parte da experiência no navegador.

Navegação entre páginas

Essa diferença aparece ao clicar em um link.

No Next.js, depois do primeiro acesso, o RSC Payload das próximas páginas é buscado antecipadamente (prefetch) e guardado em cache, e os Client Components passam a ser renderizados inteiramente no navegador, segundo a documentação de componentes. O resultado é uma navegação com cara de aplicativo, que preserva estado entre telas.

No Astro, cada link carrega um documento novo. A documentação de transições mostra duas opções. As transições nativas do navegador só adicionam animação e não colocam JavaScript extra na página. O componente <ClientRouter /> intercepta a navegação e aproxima o site de uma SPA, com estado preservado entre páginas, mas pode exigir que você reinicialize scripts manualmente.

Quando o conteúdo muda

Aqui está uma das diferenças mais práticas para quem tem muitas páginas.

O Astro, por padrão, gera tudo no build. Mudou um texto, roda um novo build. Para páginas que precisam de dados frescos, você instala um adaptador de servidor e marca a página com export const prerender = false. O resto do site continua estático.

O Next.js oferece mais mecanismos intermediários. O principal é a Regeneração Estática Incremental (ISR). A documentação de ISR lista o que ela permite: atualizar conteúdo estático sem refazer o site inteiro, servir páginas prontas na maior parte das requisições e lidar com grandes volumes de páginas sem builds longos. Você pode gerar só parte das páginas no build e criar as outras na primeira visita, ou invalidar uma página específica quando o conteúdo muda.

Desde a versão 16, lançada em outubro de 2025, o Next.js tem os Cache Components. Com a diretiva "use cache", você escolhe o que entra em cache. A documentação de caching explica que o resultado é um “casco estático” servido de uma CDN, com as partes dinâmicas chegando depois, em streaming, dentro de blocos <Suspense>. Esse modelo se chama Partial Prerendering (PPR, pré-renderização parcial).

A contrapartida é complexidade. A própria documentação de ISR lista ressalvas: o recurso só funciona no runtime Node.js, não funciona em exportação estática, e, com várias instâncias de servidor, o cache padrão é separado por instância. A documentação também avisa que a regeneração em segundo plano conta como processamento extra em plataformas que cobram por requisição.

Hospedagem

Um site Astro estático é uma pasta de arquivos HTML, CSS e JavaScript. Pode ser servido por qualquer servidor web. Para renderização sob demanda, existem adaptadores para ambientes como Node.js, Netlify, Vercel e Cloudflare, segundo a documentação de renderização sob demanda.

O Next.js também roda em vários lugares, mas com níveis diferentes de recursos. A página de deploy mostra que servidor Node.js e contêiner Docker suportam todos os recursos. A exportação estática tem suporte limitado. Os adaptadores variam: no momento da consulta, só os da Vercel e do Bun eram listados como verificados, e Cloudflare e Netlify trabalhavam em versões próprias.

A documentação de exportação estática lista o que deixa de funcionar sem servidor, entre outros: ISR, cookies, redirecionamentos e cabeçalhos configurados no framework, Server Actions e otimização de imagens com o carregador padrão. Na prática, o Next.js rende mais quando há um servidor por trás.

O que os dados de campo mostram

Para sair do campo das promessas, a redação consultou o relatório de tecnologias do HTTP Archive, um projeto independente que acompanha a web. Ele mede a fatia de domínios com bons resultados nas três Core Web Vitals: velocidade de carregamento do maior elemento (LCP), estabilidade visual (CLS) e resposta à interação (INP), no percentil 75 dos carregamentos.

Dados de agosto de 2026, o mês mais recente disponível na consulta:

Indicador	Astro	Next.js
Domínios com as três métricas boas, celular	71,0%	35,1%
Domínios com as três métricas boas, computador	83,6%	55,5%
Domínios avaliados no celular	43.850	374.612
Mediana de JavaScript na página, celular	~405 KB	~853 KB
Mediana do peso total da página, celular	~1,40 MB	~2,24 MB

Para referência, a média de todos os domínios medidos no mesmo mês foi de 53,0% no celular.

A diferença é grande e aparece também em junho e julho de 2026, no mesmo relatório. Mas ela não autoriza a conclusão de que “trocar Next.js por Astro dobra a aprovação”. Há três motivos.

• Sites diferentes. O Next.js é muito usado em aplicações, lojas e painéis, que têm mais interatividade e scripts de terceiros. O Astro se concentra em sites de conteúdo. Na avaliação da redação, boa parte da diferença vem do tipo de site, não só do framework.
• Página inicial. Segundo o FAQ do HTTP Archive, o rastreamento testa apenas a URL listada, em geral a página inicial, que pode não representar o site inteiro.
• Detecção automática. As tecnologias são identificadas pela ferramenta Wappalyzer, o que pode gerar erros de classificação.

E sobre velocidade de build? Não encontramos uma comparação independente e datada entre os dois. Os números disponíveis são de cada fornecedor. O Astro publicou, no anúncio da versão 7, builds de 15% a 61% mais rápidos em sites reais, medidos em um MacBook Pro M4 Pro. O Next.js afirmou, no anúncio da versão 16, que o empacotador Turbopack faz builds de produção de duas a cinco vezes mais rápidos que o anterior. As duas medições comparam cada framework com a própria versão anterior, não um com o outro.

Quando o Next.js é a melhor escolha

• Aplicações com login e dados por usuário, como painéis, áreas de cliente e SaaS, em que quase toda tela depende de quem está acessando.
• Interatividade em toda a interface, com muito estado compartilhado entre telas e navegação de aplicativo.
• Conteúdo que muda o tempo todo em muitas páginas, como estoque e preço, em que ISR e Cache Components evitam rebuilds completos.
• Equipe já fluente em React e no ecossistema do Next.js, com um servidor Node.js ou uma plataforma compatível à disposição.

Quando o Astro é a melhor escolha

• Publicações, blogs, documentações e catálogos em que a maior parte da página é texto, imagem e link.
• Milhares de páginas que podem ser geradas no build, como explicado em Astro: por que usar em sites com milhares de páginas.
• Hospedagem simples, em que servir arquivos estáticos é mais barato e previsível do que manter um servidor.
• Mistura de bibliotecas de interface, já que o Astro tem integrações oficiais para React, Vue, Svelte e outras e permite combiná-las na mesma página.

Projetos híbridos existem nos dois lados. O Astro pode renderizar páginas sob demanda, e o Next.js pode exportar um site estático. A pergunta útil não é qual framework é “mais rápido”, e sim qual premissa combina com a maior parte do seu projeto.

O que levar deste texto

• Astro e Next.js renderizam no servidor, mas o Astro parte de zero JavaScript e adiciona ilhas, enquanto o Next.js parte de uma aplicação React com componentes de servidor e de cliente.
• O Next.js tem mecanismos mais ricos para conteúdo que muda (ISR, Cache Components), ao custo de mais complexidade e de depender de servidor.
• Dados do HTTP Archive de agosto de 2026 favorecem o Astro em Core Web Vitals e peso de página, mas medem páginas iniciais de sites de perfis diferentes e não isolam o efeito do framework.
• Escolha pelo tipo de projeto: publicação e documentação favorecem o Astro; aplicação interativa com dados por usuário favorece o Next.js.