Por que reescrevi um produto de Next.js pra Astro

Quando o cliente pediu a reescrita completa do Bom Cristão — de 1 quiz pra 6 — a primeira pergunta não foi "qual framework é mais moderno". Foi: de onde vem o tráfego, e o que essa página realmente precisa fazer no navegador.

O produto é conteúdo, não aplicação

Landing page, blog e resultado do quiz são, na prática, documentos: texto, imagem, um botão de pagamento. Só o QUIZ em si — as perguntas, a navegação entre elas, o estado de resposta — é interativo de verdade. Rodar um bundle de aplicação inteiro (hidratação de React em cada página) pra servir o que é, na maior parte, HTML estático, é peso que o visitante paga sem ganhar nada em troca.

Islands Architecture na prática

Astro deixa cada página ser HTML estático por padrão, e só "liga" JavaScript nos componentes que realmente precisam — as islands. Nesse projeto:

• Landing, blog, página de resultado: HTML puro, zero JS enviado ao cliente.
• Componente de quiz: a única island. React apenas onde há estado real (pergunta atual, resposta selecionada, progresso).

O resultado prático: a maior parte do tráfego (que vem de busca orgânica e chega direto numa página de conteúdo) nunca baixa um bundle de aplicação. Só quem realmente inicia um quiz paga esse custo — e só nessa página.

O trade-off que valeu a pena

Trocar de framework no meio de um produto em produção tem custo real: reescrever rotas, layout, integração de pagamento. A decisão só fez sentido porque o produto vive de tráfego orgânico — performance de carregamento não é um nice-to-have, é o canal de aquisição inteiro. Um produto que depende de anúncio pago talvez não justificasse a migração.

A lição

"Qual framework é melhor" é a pergunta errada. A certa é: que fração dessa página é de fato interativa, e o resto pode ser HTML estático sem perder nada? Islands Architecture não é sobre estar na moda — é sobre não fazer o usuário pagar (em bytes, em tempo) por interatividade que a página não usa.