Astro 5 SSR no Node 22: lições do web-public em produção
Por que SSR em Astro é diferente do que Next.js te ensinou, e o que ganhamos com isso.
Astro entrou no nosso radar porque queríamos blog público (web-public) com SSR pesado e fração mínima de JS no cliente. Next.js era a escolha óbvia, mas tem viés pra app interativa. Astro tem viés pra conteúdo. A diferença aparece em métricas: web-public serve homepage em 35ms TTFB com 8KB de JS no cliente. Página de post com 12 blocos: 42ms TTFB, 12KB JS. Comparado ao mesmo conteúdo em Next.js no nosso protótipo: 80-110ms TTFB, 45KB JS.
A razão técnica é arquitetural. Astro renderiza tudo no server por padrão; JavaScript no client só roda em componentes marcados com client:* directive. Você não 'opta pra fora' de JS — você opta pra dentro. Pra blog onde 95% da interação é navegação simples, isso fecha numa página estaticamente HTML+CSS quase pura. O navegador renderiza imediatamente, sem espera por hidratação.
Adapter Node permite SSR puro — diferente de Astro estático, gera servidor que renderiza on-demand. Isso é necessário pra multitenancy: mesmo binário serve hml.camverly.dev e cafe.camverly.com com conteúdo diferente baseado em Host header. Middleware de Astro resolve site_id antes da página renderizar, e cada loader puxa do tenancy/authoring com aquele site_id. Funciona como qualquer SSR maduro, mas sem o overhead de framework.
Onde dói: integração com Tailwind 4 alpha. Astro 5 usa @astrojs/tailwind como integração oficial, e Tailwind 4 tem PostCSS plugin novo que ainda não é compatível. Caímos no bug e voltamos pra Tailwind 3.4, que funciona perfeitamente. Bug é problema de timing entre dois projetos, não de Astro em si, mas vale alerta. Outro ponto: hot reload em SSR é mais lento que Next.js — 2 segundos pra recompilar mudança, comparado a 500ms.
O que faz Astro brilhar: a separação entre lógica de dados e markup. Eu modelo middleware que resolve site, cada page faz fetch específico, components recebem props tipadas, tudo no server. Cliente é dumb. Pra time backend que prefere razoar sobre fluxo de dados a sobre lifecycle de hook, Astro encaixa. Pra app altamente interativa, continuaria escolhendo Next.js. Pra blog público, Astro é decisão fácil que paga em performance percebida pelo usuário.