Astro 5+
Mi veredicto
Elección por defecto para frontends headless con mucho contenido. Las islas zero-JS ganan en Core Web Vitals.
Brief de profesional
Por qué lo adoptamos
Migramos wppoland.com de Next.js 13 pages router a Astro 5 en marzo de 2026. El LCP de la home pasó de 2,4 s a 1,1 s en un perfil Moto G Power, el bundle de JS de una página de contenido bajó de 187 KB gzipped a 9 KB (una sola isla de Search), y el tiempo de build completo en frío cayó de 11 min 30 s en Vercel a 7 min 30 s en local con el heap de 16 GB de scripts/stable-build.sh. La Content Layer API (RFC 0050, Astro 5.0) trata MDX, JSON y contenido remoto bajo una única superficie getCollection, lo que colapsa tres adaptadores heredados de la etapa Next.js.
Cuándo lo usamos
Superficies de marketing con mucho contenido: páginas pilar, matrices comparativas, páginas de ciudad programáticas, documentación, blogs. Renderizado mayoritariamente estático, islas aisladas (búsqueda, un toggle de precios, un gráfico), ciclo de edición con Markdown y colecciones MDX. No recurrimos a Astro cuando el encargo tiene forma de aplicación: paneles autenticados, checkouts con estado de carrito compartido, cualquier cosa donde el modelo correcto sea React renderizado en cliente o streaming de RSC. Para eso seguimos con Next.js 15.
Ruta de migración
La mayoría de equipos llega desde Next.js 13/14 pages router (la ruta más limpia, getStaticProps se mapea casi 1:1 a colecciones de Astro), desde Gatsby v5 (el esquema GraphQL es la parte dura; el file router y MDX portan bien) o desde un monolito WordPress que pasa a headless (trátalo como greenfield, conecta WPGraphQL o REST). Lo que no se transfiere: el contexto de React, el estado solo de cliente (Zustand, Jotai) y el middleware de Next.js. Calcula ~1 día por cada 30 páginas de contenido, más una semana dura para convertir shells de React a Astro.
Dos cicatrices de producción
Primera, View Transitions en iOS Safari 17.4: al hacer clic en un enlace generado desde MDX durante una transición, los scripts de las islas nuevas se ejecutaban antes de intercambiar el DOM antiguo, lo que dejaba listeners obsoletos enganchados y la búsqueda rota en la segunda navegación. Solución: transition:persist="search" y <ClientRouter /> en lugar del import heredado <ViewTransitions /> (el PR #12029 de Astro lo estabilizó en 5.2). Segunda, MDX con remark-shiki en un build de Cloudflare Pages: shiki intentó cargar más de 90 gramáticas y provocó un OOM en un worker de 4 GB. Arreglo: fijar shikiConfig.langs a ['ts', 'js', 'php', 'json', 'bash']. La memoria de build bajó de 3,8 GB a 1,2 GB.
Qué estamos vigilando
Server Islands (Matthew Phillips, RFC 0040, incluido en 5.0) es el camino hacia la personalización dinámica selectiva dentro de una página estática; lo estamos pilotando en el toggle de precios, pero lo mantenemos fuera del resto del sitio hasta que se estabilicen las cabeceras de caché (astro/#11437). La Container API para testear componentes con vitest está en nuestra lista corta en cuanto se publique el PR #11952 de Bjorn Lu. Y Astro DB: Turso lo recompró a principios de 2026 y la historia de migración para sitios con astro:db sigue abierta (astro/#12188).
Añadido: 2026-04-26 · Última revisión: 2026-04-26