Como escolher a tecnologia da tela da sua loja

A pergunta que trava a maioria dessas decisões está mal formulada. "Qual tecnologia é a melhor?" não tem resposta útil. A resposta honesta é "depende da tela". A página de campanha, a página de produto com variações e o painel de controle exigem níveis de interação bem diferentes. Tratar tudo com a mesma ferramenta quase sempre desperdiça velocidade ou tempo de desenvolvimento.

Este guia dá uma régua de decisão por tela. Ela liga ao que importa para uma loja de porte médio no Brasil. O peso do código no celular, o esforço do time e a facilidade para o Google e a IA lerem a página. Ele fecha a trilha de três guias mais técnicos: 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. Cada família tem um ponto ótimo diferente.

• Conteúdo e marketing: home de campanha, blog, central de ajuda.
• Storefront transacional: listagem com filtros, página de produto, carrinho.
• Back-office: painel de pedidos, relatórios, configurações com login.

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 que o coletor de LLM encontra

Dados dependem de JavaScript no cliente

• O coletor lê o HTML sem executar JavaScript
• Nome, preço e descrição ficam de fora
• A sua loja some da resposta

Dados preenchidos no servidor

• Nome, preço e descrição já estão no HTML
• O coletor lê sem executar nada
• A sua loja entra na resposta

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 e dispensa um framework único.

Aqui, o sistema visual da marca importa mais que a tecnologia escolhida. Um padrão único de cor, fonte e espaçamento resolve isso. O botão tem a mesma aparência em qualquer tela, porque todas usam o mesmo padrão. Esse é o tema do guia de design system para e-commerce, o próximo passo natural depois de decidir a tecnologia.

O que fazer com essa lista agora?

Faça esse exercício com o seu desenvolvedor: listem as dez páginas mais visitadas da loja e classifiquem cada uma em conteúdo, catálogo ou painel de controle. Depois, meçam quanto de código cada uma carrega hoje no celular. As páginas de conteúdo pesadas são as primeiras candidatas a ficar mais leves. Depois disso, unifiquem o visual com um padrão único e sigam para o guia de design system e CSS moderno.