Como escolher a stack de frontend do seu e-commerce: Astro, Next ou Svelte

A pergunta que trava a maioria das decisões de frontend no e-commerce está mal formulada. “Qual framework é o melhor?” não tem resposta útil, porque a resposta honesta é “depende da rota”. A vitrine de campanha, a página de produto com variações e o painel administrativo têm cargas de interatividade tão diferentes que tratar tudo com a mesma ferramenta quase sempre desperdiça desempenho ou produtividade.

Este guia oferece uma régua de decisão por rota, ligada ao que importa para uma operação brasileira mid-market: peso de JavaScript no celular do cliente, esforço do time e legibilidade do HTML para buscadores e motores generativos. Ele fecha a trilha dos três guias de stack: Astro e islands, Next 16 com React 19 e Svelte 5 com SvelteKit.

Qual é a pergunta certa antes de escolher a stack?

Resposta direta: qual a proporção entre conteúdo estático e interatividade na rota que você vai construir. Quanto mais a página é leitura (blog, guia, landing, página institucional), mais ela pede uma ferramenta que envia quase nada de JavaScript. Quanto mais a página é aplicação (carrinho, filtros, dashboard, login), mais ela pede um framework feito para estado e interação.

Pense em três famílias de rota numa loja típica. A primeira é conteúdo e marketing: home de campanha, blog, central de ajuda. A segunda é o storefront transacional: listagem com filtros, página de produto, carrinho. A terceira é o back-office: painel de pedidos, relatórios, configurações com login. Cada família tem um ponto ótimo diferente.

Quando cada stack é a escolha certa?

Resposta direta: Astro para rotas de conteúdo, Svelte para storefront reativo e leve, Next para aplicações e dashboards React com login. A tabela abaixo resume a régua.

Critério	Astro	Next.js 16 + React 19	Svelte 5 + SvelteKit
Ponto ótimo	Conteúdo premium: blog, docs, marketing	Apps, dashboards, produtos com login	Storefront reativo e leve
JavaScript no cliente	Mínimo (zero por padrão; islands sob demanda)	Maior (runtime React; mitigado por RSC)	Pequeno (reatividade compilada, sem virtual DOM)
Modelo de render	SSG/SSR + islands	RSC + SSR + PPR/Cache Components	SSR por padrão + hidratação enxuta
Ecossistema	Cresce; usa componentes de qualquer framework	O maior do mercado	Menor, porém coeso
Curva para time React	Baixa (renderiza React como island)	Nenhuma	Média (runes são novas)
Melhor sinal para GEO	Excelente (HTML estático rápido)	Bom (SSR/streaming)	Excelente (HTML leve no servidor)

A leitura da tabela não pede que você escolha uma linha e ignore as outras; ela serve para localizar a rota na régua. Uma central de conteúdo que precisa de uma caixa de busca interativa é Astro com uma island de busca. Um painel de pedidos com login e dados ao vivo é Next. Uma página de produto com filtros, variações e carrinho, num público majoritariamente mobile, é forte candidata a Svelte ou a Astro com islands.

Por que as três servem ao GEO, e o que realmente decide?

Resposta direta: porque Astro, Next (App Router) e SvelteKit renderizam HTML no servidor, e HTML preenchido é o que crawlers e coletores de LLM leem sem executar JavaScript. O que decide o GEO não é o logo do framework, e sim a disciplina de servir conteúdo no servidor, com dados estruturados e tempo de carregamento curto.

O motor generativo não pergunta qual framework você usou. Ele lê o HTML que chega. Se o nome, o preço e a descrição do produto estão lá no servidor, a sua loja entra na resposta; se dependem de um JavaScript que o coletor não executa, a sua loja some.

O detalhe que separa um bom resultado de um ruim é a arquitetura por trás da vitrine. Qualquer uma das três stacks rende mais quando conversa com um back-end desacoplado, como descrito em Composable, MACH e headless API-first. A camada de apresentação troca; o contrato de dados permanece.

Como combinar stacks sem virar colcha de retalhos?

Resposta direta: separe por domínio de rota e una pelo back-end e pelo design system. Marketing e conteúdo num projeto Astro, storefront em Svelte ou Astro, back-office em Next, todos consumindo as mesmas APIs e o mesmo conjunto de tokens de design. A coerência visual vem dos tokens compartilhados, não de um framework único.

É aqui que o sistema de design importa mais que o framework. Se a cor primária, a tipografia e o espaçamento vivem como tokens (idealmente em OKLCH, com contraste WCAG AA garantido), o botão tem a mesma aparência em Astro, em React e em Svelte, porque todos consomem a mesma variável. Esse é o tema do guia de design system, tokens e CSS moderno para e-commerce, o próximo passo natural depois de decidir a stack.

Próximo passo

Faça o exercício concreto: liste suas dez rotas de maior tráfego, classifique cada uma em conteúdo, storefront ou back-office, e marque o peso de JavaScript que cada uma carrega hoje no celular. As rotas de conteúdo pesadas são as primeiras candidatas a migrar para Astro; as de storefront travadas, para Svelte ou islands. Depois, unifique a camada visual com tokens compartilhados e siga para o guia de design system e CSS moderno.