Astro 5+
O meu veredicto
Escolha padrão para frontends headless com muito conteúdo. Ilhas zero-JS ganham nos Core Web Vitals.
Briefing do profissional
Porque o adotámos
Migrámos o wppoland.com do pages router do Next.js 13 para o Astro 5 em março de 2026. O LCP na homepage passou de 2,4s para 1,1s num perfil Moto G Power, o bundle de JS numa página de conteúdo caiu de 187 KB gzipped para 9 KB (uma única ilha Search) e o tempo de cold build de todo o site desceu de 11 min 30s na Vercel para 7 min 30s localmente, com a heap de 16 GB em scripts/stable-build.sh. A Content Layer API (RFC 0050, Astro 5.0) trata MDX, JSON e conteúdo remoto sob uma única superfície getCollection, eliminando três adaptadores da era Next.js.
Quando recorremos a ele
Superfícies de marketing orientadas a conteúdo: páginas pilar, matrizes comparativas, páginas de cidade programáticas, documentação, blogues. Render maioritariamente estático, ilhas isoladas (pesquisa, um toggle de preços, um gráfico), ciclo de edição através de Markdown e coleções MDX. Não recorremos ao Astro quando o briefing tem forma de aplicação: dashboards autenticados, checkouts com estado de carrinho partilhado, tudo aquilo em que o modelo certo é React renderizado no cliente ou streaming de RSC. Para esses casos ficamos no Next.js 15.
Caminho de migração
A maioria das equipas chega do pages router do Next.js 13/14 (o caminho mais limpo, o getStaticProps mapeia quase 1:1 para coleções Astro), do Gatsby v5 (o schema GraphQL é a parte difícil; o file router e o MDX portam-se bem) ou de um monólito WordPress a passar a headless (trate-o como greenfield, ligue WPGraphQL ou REST). O que não transita: contexto do React, estado só de cliente (Zustand, Jotai), middleware do Next.js. Conte com cerca de 1 dia por cada 30 páginas de conteúdo, mais uma semana difícil para converter shells de React para Astro.
Duas cicatrizes de produção
Primeira, as View Transitions no iOS Safari 17.4: clicar num link gerado por MDX durante uma transição disparava os scripts das novas ilhas antes de o DOM antigo ser substituído, deixando listeners obsoletos ligados e a pesquisa avariada na segunda navegação. Contorno: transition:persist="search" e <ClientRouter /> em vez do import legado <ViewTransitions /> (o PR #12029 do Astro estabilizou isto no 5.2). Segunda, MDX com remark-shiki num build do Cloudflare Pages: o shiki tentou carregar mais de 90 gramáticas e provocou OOM num worker de 4 GB. Correção: fixar shikiConfig.langs em ['ts', 'js', 'php', 'json', 'bash']. A memória de build caiu de 3,8 GB para 1,2 GB.
O que estamos a observar
As Server Islands (Matthew Phillips, RFC 0040, no 5.0) são o caminho para personalização dinâmica seletiva dentro de uma página estática; estamos a testá-las no toggle de preços, mas seguramos a adoção em todo o site até os cabeçalhos de cache estabilizarem (astro/#11437). A Container API para testar componentes com vitest está na nossa shortlist assim que o PR #11952 do Bjorn Lu for lançado. E o Astro DB: a Turso comprou-o no início de 2026 e a história de migração para sites com astro:db continua em aberto (astro/#12188).
Adicionado: 2026-04-26 · Última revisão: 2026-04-26