Fazer sites não é uma coisa muito recorrente, principalmente se o seu foco é engenharia e arquitetura, mas com o Rush CMS minha demanda mudou um pouco, e pude ter muitas reflexões sobre a melhor estrutur que encontrei para o meu fluxo de trabalho quando se trata de um Headless CMS. Se você ainda faz site, ou gerencia quem faz, esse artigo pode ser muito útil.
Já adianto que não vou tentar te converter, zero discussão de framework como religião! O que eu tenho pra te mostrar é chato, mas útil: hoje rodo 10 sites de clientes em Astro, a grande maioria servidos pelo Rush CMS, do meu próprio rafhael.pro à home da CTB Brasil com mais de 30 fotos (e Pagespeed Insights nota 97), passando por site de construtora, de escola, padaria, farmácia... É um portfólio real, em produção, pagando boleto. Este post é a contabilidade do que o Astro me dá nesse cenário, e no fim também explico por que ele não é a ferramenta certa.
O problema que o Astro resolve pra mim
A maioria dos sites que entrego é o que o time do Astro chama, com honestidade, de "content-driven": institucional, landing page, blog, portfólio. Esses são sites onde o conteúdo precisa chegar rápido ao leitor, e não dashboards logados ou redes sociais, então eles precisam ser rápidos, por vezes mais rápido do que bonito.
O problema é que a indústria passou anos empurrando ferramenta de web app pra resolver website. Next.js e Nuxt são bons pra app complexo com estado global e área logada. Mas o modelo SPA deles foi desenhado pra renderizar o site inteiro no cliente, e o SSR entrou depois, majoritariamente pra remediar performance. Pra uma landing page ou site cujo único trabalho é entregar a mensagem e converter, mandar um runtime de React no primeiro load é mais que chover no molhado: é perder dinheiro.
O Astro inverte isso: é server-first por padrão. Astro segue a mesma abordagem que PHP, WordPress, Laravel e Rails usam há décadas, só que sem você precisar aprender uma segunda linguagem de servidor, porque continua tudo HTML, CSS e JavaScript. Relato pessoal: Eu, particularmente, detesto o Dinossauro do Wordpress, e não quero ter que apertar todos os botões do avião com Next.js para uma landing page (felizmente, está no meu passado obscuro), quero entregar o melhor trabalho possível da forma mais necessária possível. A primeira vez que testei Astro, me senti voltando pra casa, mas com um tooling moderno.
O que é a Arquitetura de Ilhas?
Essa é uma ideia bem elegante e é simples de explicar, tem consequência direta na conta de performance: em vez de hidratar a página inteira no navegador, o Astro renderiza tudo como HTML estático e isola a interatividade em "ilhas" que carregam JavaScript só quando precisam. Na prática, no caso do Rush CMS, isso significa que 90% de um site institucional (header, hero, textos, footer) sai como HTML puro, sem nenhum JS no cliente. Se a página tem um formulário de contato ou um carrossel, só esse componente carrega script:
---// O arquivo .astro renderiza no servidor. Header, Hero e Footer// viram HTML puro: zero JavaScript enviado ao cliente.
import Header from '../components/header.astro'import Hero from '../components/hero.astro'import ContactForm from '../components/contact-form.ts'import Footer from '../components/footer.astro'---
<Header /><Hero /><!-- O JS só carrega quando o componente entra na viewport --><ContactForm client:visible /><Footer />A diretiva client:visible é o detalhe que importa: o formulário só baixa e executa o js quando o usuário rola até ele. Numa landing page, isso costuma significar que o JS nunca é baixado, porque o CTA já converteu antes.
E os números? Me dê os números!
Segundo a documentação oficial, Astro pode entregar um site 40% mais rápido, com 90% menos js que (provavelmente) Next.js.
No artigo Por que a velocidade é importante, é destrinchado - com casos reais - o impacto cada projeto pode ter em deixar sua estrutura e site mais rápido, independente da linguagem que é usada, lá tem cases como "A cada 100ms mais rápido, a Mobify registrou 1% mais conversões", "A Pinterest cortou 40% no tempo de carregamento e ganhou 15% mais cadastros" e "A AutoAnything ficou 50% mais rápida e vendeu 12% mais".
É possível fazer isso com React, Next.js ou qualquer framework da moda. Mas, se tratando de sites, por que vou reinventar a roda se já tenho em mãos um framework extremamente fácil de usar e que entrega um resultado incrível com tão pouco? Performance tem impacto financeiro mensurável, e que a arquitetura do Astro torna performance o default em vez de uma batalha constante.
No meu caso mais recente, o site da CTB Brasil (link no começo do post), uma home com mais de 30 fotos, medi 97 no Lighthouse mobile, com mais de trinta imagens que normalmente seriam um massacre de performance sem ter que fazer nada demais: astro:assets, lazy loading, WebP automático, sem suar!
Tudo termina na flexibilidade e praticidade
Essa parte eu gosto, muito! Astro é UI-agnostic. Se precisar, fique a vontade para usar React, Vue, Svelte, Solid, ou o que for nas suas ilhas. Na prática isso quer dizer que se amanhã eu decidir que o Svelte resolve melhor um componente específico, ou herdar um componente Vue de um projeto antigo, eu não reescrevo o site.
Astro + Bun
Se o Astro resolve a performance do lado do cliente, o Bun ataca o outro lado da conta: o tempo de build e o CI/CD. O Astro suporta o Bun oficialmente, mas eu gosto de usar essa abordagem:
bun create astroVou ser específico no ceticismo de novo: os ganhos de velocidade do Bun são reais e bem documentados em instalação de dependências e cold start, mas o número exato depende do seu projeto e do seu runner. Eu uso a combinação no dia a dia e o ganho aparece principalmente onde mais dói, no pipeline que roda a cada push.
Onde o Astro NÃO é a resposta
Você provavelmente já deve saber, eu uso Astro para sites e landing pages, para qualquer outra coisa, eu vou para o bonito Svelte ou o feio React (feio sim, mas que paga as contas), tentar forçar Astro em UI de sistemas, plataformas, e etc. me parece um grande tiro no pé, não é impossível, mas limitante.
E você? já testou o Astro quando precisou fazer alguma página web, ou já delegou tudo para o agente de IA que ama um Next.js?