Astro vs Next.js vs SvelteKit: como escolher sem tabela inventada
Escolher um framework frontend não é trivial: Astro, Next.js e SvelteKit são maduros e têm filosofias bem diferentes. Este guia compara os três por aquilo que cada um decide por você, que é o critério que sobrevive à próxima versão menor.
Uma nota sobre a tabela que não está aqui. A versão anterior deste post trazia um comparativo com tempo de build, bundle, TTFB e nota de Lighthouse, legendado como “valores coletados de projetos reais”. Não há medição por trás daqueles números e eles foram removidos, junto com dois estudos de caso que descreviam projetos que não existem. No lugar entrou a seção 6: como medir os três no seu projeto, que é a única versão desse comparativo que vale para você, porque a sua página não é a minha.
1. O que cada um decide por você
| Framework | A decisão que ele toma | O que isso custa |
|---|---|---|
| Astro | Nenhum JavaScript vai para o cliente, a menos que você peça | Interatividade é opt-in: você declara ilha por ilha |
| Next.js | Você está no ecossistema React, servidor e cliente no mesmo modelo | Complexidade conceitual (o que roda onde) e mais JS na base |
| SvelteKit | O framework some no build; o que chega ao browser é o seu código compilado | Ecossistema menor: mais coisa você escreve, menos você instala |
Essa é a comparação que não vence com o tempo. As outras, número de plugins, tempo de build, tamanho de bundle, mudam a cada versão e dependem mais do que você escreve do que do framework.
2. Astro: performance que vem de fábrica
Astro entrega zero JavaScript por padrão. Você escreve HTML, CSS e componentes, e o framework só manda JS quando você marca um componente como interativo.
- Islands architecture: componentes interativos são “ilhas” num mar de HTML estático. Cada ilha carrega o próprio JS de forma independente e adiada.
- Content collections: conteúdo com schema validado por Zod, que quebra o build quando um post tem frontmatter errado. Para blog e documentação, é a feature que mais paga.
- Server islands: componente que renderiza no servidor dentro de uma página estática, conteúdo dinâmico sem transformar a página inteira em SSR.
- View transitions e otimização automática de imagem, fonte e CSS.
É a melhor escolha para site em que o conteúdo é o produto: blog, documentação, landing page, portfólio, institucional. Este blog roda em Astro, e a razão é literalmente a segunda linha da lista: o schema das collections é o que impede um post de ir ao ar quebrado.
3. Next.js: o ecossistema React na forma mais madura
Next.js é a escolha natural de quem já está em React. O App Router é o padrão, e os React Server Components são o coração da arquitetura.
- App Router: roteamento por diretório, com layout aninhado, estado de carregamento e fronteira de erro embutidos.
- Server Components: componentes que rodam só no servidor, tirando código do bundle do cliente.
- Server Actions: função de servidor chamada direto do cliente, sem você escrever uma rota de API para cada mutação.
- Renderização incremental: partes estáticas e dinâmicas na mesma página, e revalidação sem rebuild completo.
Brilha em aplicação full-stack: painel, SaaS, marketplace, qualquer coisa com autenticação e dado por usuário. O custo é conceitual, a pergunta “isso roda no servidor ou no cliente?” passa a acompanhar cada componente que você escreve.
Uma ressalva de versão, porque este ponto envelhece rápido: o Next.js muda de
major com frequência e o comportamento do App Router mudou entre elas. Confira a
documentação da versão que está no seu package.json antes de copiar
qualquer padrão daqui ou de qualquer outro post.
4. SvelteKit: simplicidade com reatividade explícita
O sistema de runes resolveu o maior ponto de confusão do Svelte, a
reatividade implícita. Hoje você declara o que é reativo: $state() para estado,
$derived() para valor computado, $effect() para efeito colateral.
- Compilação: Svelte compila para JavaScript direto, sem virtual DOM e sem runtime pesado acompanhando a aplicação.
- Form actions: formulário tratado no servidor com melhoria progressiva, ou seja, funcionando mesmo sem JS.
- Adaptadores: o mesmo projeto sai para várias plataformas trocando um adaptador.
É a escolha para alta performance com pouca cerimônia: app interativo, ferramenta interna, protótipo, e qualquer projeto em que o tamanho do bundle é requisito de verdade, público em rede ruim, por exemplo.
5. Recomendação por perfil de projeto
| Seu projeto | Escolha |
|---|---|
| Blog, landing page, portfólio, documentação | Astro |
| SaaS, marketplace, painel com autenticação | Next.js |
| App interativo, ferramenta interna, protótipo | SvelteKit |
| Site de conteúdo com trechos interativos | Astro + ilhas |
| Público em rede lenta, bundle é requisito | SvelteKit |
| Time que já é experiente em React | Next.js |
A última linha da tabela é a que mais decide na prática, e nenhuma medição sintética captura: o melhor framework costuma ser o que o time já sabe depurar às duas da manhã.
6. Como medir os três no SEU projeto
Um benchmark de blog compara páginas que não são a sua. O comparativo que serve para decidir leva meia tarde e você escreve o método junto:
- Escolha UMA página real do seu produto, a mais visitada, não a mais simples. Se ela tem lista, filtro e um gráfico, é ela.
- Implemente a mesma página nos três. Sem otimizar nenhuma além do padrão do framework, senão você está medindo o seu carinho, não a ferramenta.
- Meça na mesma máquina, no mesmo dia, com o cache limpo. Anote a máquina, a versão de cada framework e a data. Sem isso, o número não é reproduzível nem por você daqui a um mês.
- Meça quatro coisas, nesta ordem de importância: JavaScript que chega ao browser na primeira visita; tempo até a página ficar interativa numa conexão ruim simulada; tempo de build com o número de páginas que você vai ter em um ano, não hoje; e quanto tempo você levou para escrever cada versão.
- Publique o método junto do resultado, nem que seja num README interno. É o que permite alguém discordar do número em vez de acreditar nele.
O quarto item costuma decidir sozinho, e é o único que nenhum benchmark público mede: quanto tempo VOCÊ levou.
Conclusão
Não existe bala de prata. Os três são excelentes, e a escolha é entre as decisões que cada um toma no seu lugar: Astro decide que o padrão é não mandar JS; Next.js decide que servidor e cliente vivem no mesmo modelo mental; SvelteKit decide sumir no build.
Escolha pela decisão que você quer ter tomada. E, se o desempate for número, meça o seu, com a máquina, a data e o método escritos ao lado.
Douglas Haruo, engenheiro de software há 15 anos, cinco deles em risco e fraude numa fintech de pagamentos. haruo.dev
Precisa de um projeto técnico sob medida?
Arquitetura, TypeScript, APIs e automação, do protótipo à produção. Quem responde o seu e-mail é quem escreve o código, e o prazo que eu prometo é o prazo que eu consigo cumprir.
Me manda uma mensagem →