Astro 5 salió el 3 de diciembre de 2024 y llega a septiembre de 2025 con nueve meses de rodaje, suficientes para que las primeras impresiones de lanzamiento se contrasten con la experiencia real. Este post no es una revisión del día uno. Es una valoración con tiempo de lo que ha funcionado, lo que ha costado y dónde Astro ha dejado definitivamente su marca en el ecosistema JavaScript. Ya cubrimos el modelo de islas de Astro cuando debutó, en Astro y las islas: la web que envía menos JavaScript; este artículo retoma la historia cinco versiones después.

Puntos clave

  • La Content Layer de Astro 5 generaliza las Content Collections para cubrir cualquier fuente de datos (CMS remoto, API, base de datos) como colección tipada con schema Zod y garantías en tiempo de construcción.

  • Server Islands permite incluir bloques de renderizado bajo demanda dentro de páginas estáticas sin convertir toda la página en dinámica. El TTFB se mantiene en 50 ms desde CDN aunque el bloque muestre contenido personalizado.

  • Una página típica de blog en Astro 5 envía menos de 10 KB de JavaScript residual, frente a los ~40 KB de Astro 4, una diferencia visible en móvil con 4G lento.

  • El tiempo de compilación ha aumentado: ~18 s para 500 páginas frente a ~12 s en Astro 4, por la validación de schemas de Content Layer. Es revisable con caché de contenido.

  • Astro 5 no compite directamente con Next.js (aplicaciones con interactividad dominante) ni con Hugo/Eleventy (contenido puramente estático): su espacio son los sitios donde contenido y aplicación conviven.

La capa de contenido como hito real

La novedad más importante de Astro 5 es sin discusión la Content Layer. En Astro 4 las Content Collections ya permitían tipar contenido Markdown y JSON locales, pero estaban limitadas a archivos del repositorio. La Content Layer generaliza ese concepto: cualquier fuente de datos se puede modelar como una colección tipada. Sea un CMS remoto, una API, una base de datos o un sistema de archivos, el esquema Zod es el mismo y las garantías en tiempo de construcción también.

El cambio es más profundo de lo que parece. En los últimos tres años el patrón dominante en sitios JavaScript ha sido consumir datos en tiempo de ejecución mediante fetches o GraphQL, con tipado manual mediante generadores externos. Astro propone invertirlo: el contenido se carga en tiempo de construcción, se valida, se tipa y se expone como una colección consultable. Para sitios donde el contenido cambia con frecuencia baja o media, este modelo elimina capas enteras de complejidad en tiempo de ejecución.

En mi caso, he migrado un par de sitios que consumían datos de un Sanity y de un WordPress desacoplado. En ambos la Content Layer ha reducido el código de integración a un adaptador de treinta líneas que describe el esquema y hace una llamada a la API del CMS. El resto de la aplicación no sabe ni le importa si el dato viene de Sanity, de WordPress o de un archivo local. Esta abstracción uniforme es lo más Astro que hay.

Server Islands: la arquitectura que encaja

El otro cambio estructural es la introducción de Server Islands, que generaliza el modelo de islas de interactividad para permitir también islas de renderizado dinámico dentro de páginas estáticas. En Astro 4 una página era estática o renderizada en servidor, y mezclar los dos modelos requería trucos. En Astro 5 una página estática puede incluir bloques concretos que se renderizan bajo demanda, como un panel de usuario, un contador de stock o una sección personalizada. Nada de eso convierte toda la página en dinámica.

Esto encaja con cómo se reparte el contenido en los sitios web modernos:

  • Un blog tiene 95 % de contenido estático pero un 5 % que cambia: comentarios, valoraciones, datos del usuario autenticado.

  • Una tienda tiene catálogo estático pero disponibilidad dinámica.

  • Un medio de comunicación tiene artículos estáticos con secciones de últimos titulares o personalización por región.

En todos estos casos, Server Islands permite servir la página desde CDN como si fuera estática y solo golpear el servidor para los bloques concretos que lo necesitan. La implementación usa un componente especial con directiva server:defer que se renderiza en el servidor cuando la página se solicita, mientras el resto de la página viene de CDN. El resultado es que una página puede tener TTFB de 50 milisegundos desde CDN y seguir mostrando contenido personalizado.

Rendimiento medido con calma

Un patrón que se repite en los sitios que he migrado es que el tiempo hasta pintar contenido en móvil ha bajado sensiblemente. No por nada dramático, sino porque Astro 5 compila el entorno con más rigor y elimina más JavaScript innecesario. Una página típica de blog que en Astro 4 enviaba 40 KB de JavaScript residual, en Astro 5 envía menos de 10. En un dispositivo de gama media con red 4G lenta, la diferencia en primer renderizado se cuenta en cientos de milisegundos.

El lado no tan bueno es que el tiempo de compilación ha aumentado. Un sitio con 500 páginas que en Astro 4 construía en 12 segundos, en Astro 5 tarda unos 18. La razón es la validación de schemas de Content Layer en toda colección, que es más exhaustiva. Para sitios pequeños esto es irrelevante, pero cuando el número de colecciones crece conviene revisar la configuración de caché de contenido.

Logotipo de Astro, el framework que en su versión 5 consolida el modelo Content Layer y Server Islands para sitios donde contenido estático y componentes dinámicos coexisten sin sacrificar el rendimiento de primer renderizadoLogotipo de Astro. Su versión 5 consolida el modelo Content Layer y Server Islands. Sirve para sitios donde contenido estático y componentes dinámicos coexisten sin sacrificar el rendimiento de primer renderizado (Imagen: Unknown authorUnknown author, CC BY-SA 4.0, vía Wikimedia Commons)

El problema de la integración con React y Vue

Astro 5 mantiene la idea de agnóstico frente a entornos de interfaz, pero el nivel de pulido varía mucho según cuál elijas:

  • React 19: excelente, incluyendo soporte para Server Components en modo experimental.

  • Vue 3: funciona bien pero hay casos de borde con directivas personalizadas.

  • Svelte 5: sólido.

  • Solid: bueno.

  • Lit: adecuado pero menos cuidado.

El problema es que cuando conviven dos o más entornos en el mismo proyecto, algunos patrones solo funcionan bien en uno. Mi recomendación, después de probarlo en proyectos reales, es que si vas a mezclar entornos, el motivo tiene que ser concreto, no solo por probar. Un solo entorno de interfaz por proyecto simplifica la experiencia.

View Transitions maduras

Otra área que ha ganado mucho en Astro 5 es el soporte de View Transitions, la API del navegador que permite transiciones animadas entre páginas sin tener que construir una SPA completa. En Astro 4 estaba marcada como experimental y tenía casos de borde feos con rutas anidadas. En Astro 5 es estable y funciona en los navegadores modernos que ya implementan la API.

El efecto práctico es que un sitio Astro puede tener transiciones de página suaves tipo aplicación, manteniendo elementos persistentes entre rutas, sin perder la ventaja arquitectónica de ser un sitio multipágina. He montado un par de sitios con esto y la diferencia de percepción de calidad es notable. No es un argumento para elegir Astro sobre otros entornos, pero es una razón más para no descartarlo.

Para los sitios de contenido de jacar.es, la arquitectura de Astro 5 con Content Layer encaja directamente con el flujo editorial. El contenido viene de múltiples fuentes (archivos Markdown, taxonomías, datos de autor) y necesita garantías de tipo en tiempo de construcción antes de publicar.

Dónde sigue flojo

No todo es positivo en Astro 5. Hay dos áreas donde todavía veo resistencia:

Primera: el ecosistema de componentes pre-construidos. Frente a Next.js, donde hay miles de componentes, layouts y plantillas listos para copiar, Astro tiene un ecosistema mucho más pequeño. Para equipos que dependen de arrancar rápido con componentes existentes, la diferencia es notable.

Segunda: la curva de aprendizaje para desarrolladores acostumbrados a React. Astro tiene un modelo mental propio que no es el de los entornos SPA clásicos. La división entre componentes .astro que son de servidor por defecto, y componentes de entorno que son islas, cuesta interiorizarla. He visto equipos perder semanas intentando usar patrones de Next.js en Astro antes de rendirse y adoptar el modelo nativo.

Mi lectura

Astro 5 ha terminado de consolidar un espacio propio entre los entornos web. No compite directamente con Next.js, que sigue siendo la opción obvia para aplicaciones donde la interactividad domina. No compite directamente con Hugo o Eleventy, que siguen siendo los reyes del contenido puramente estático.

Compite en un espacio intermedio real: sitios donde contenido y aplicación conviven. La interfaz es estática salvo bloques dinámicos concretos, y el SEO y el rendimiento en el primer renderizado importan.

Ese espacio intermedio resulta ser mucho más grande de lo que parecía hace dos años:

  • Blogs con zonas de miembros

  • Medios con comentarios personalizados

  • Portfolios con CMS

  • Tiendas pequeñas con catálogo estático y proceso de compra dinámico

  • Sitios de documentación con contenido de producto enriquecido

Mi recomendación concreta es que si estás empezando un proyecto nuevo que no es claramente una aplicación con interfaz intensiva, Astro 5 merece una evaluación seria. Probablemente termines con menos código, menos dependencias y mejor rendimiento que con Next.js, sin renunciar a las capacidades dinámicas que ocasionalmente necesites. Si tu proyecto es una aplicación con mucha interactividad, sigue con lo que ya usas. La herramienta no es neutra: encaja en unas formas de trabajar y choca con otras, y no pretender adaptarla a todo es parte de su valor.

Este artículo también está disponible en inglés: Astro 5: when content and applications converge.

Fuentes:

  1. Anuncio oficial de Astro 5.0 en el blog de Astro[1]
  2. Content Collections y la Content Layer API, documentación de Astro[2]
  3. Server Islands, documentación de Astro[3]
  4. Notas de la versión astro@5.0.0 en GitHub[4]

Preguntas frecuentes

¿Puedo tener contenido personalizado en una página estática de Astro 5 sin perder el TTFB de CDN?

Sí, con Server Islands. Marcas el bloque concreto (un panel de usuario, un contador de stock, una sección personalizada) con la directiva server:defer. Se renderiza en el servidor cuando se solicita la página, mientras el resto se sirve desde CDN como estático. El resultado es un TTFB de 50 milisegundos desde CDN con contenido personalizado, sin convertir toda la página en dinámica como ocurría en Astro 4.

¿Por qué tarda más en compilar mi sitio tras migrar a Astro 5?

Por la validación de schemas de la Content Layer, que ahora se aplica de forma más exhaustiva a todas las colecciones. Un sitio de 500 páginas que en Astro 4 construía en unos 12 segundos pasa a tardar unos 18 en Astro 5. Para sitios pequeños es irrelevante; cuando el número de colecciones crece, conviene revisar la configuración de caché de contenido. A cambio, una página típica de blog envía menos de 10 KB de JavaScript residual frente a los 40 KB de Astro 4.

¿Es buena idea mezclar React y Vue en un mismo proyecto Astro 5?

Solo si hay un motivo concreto, no por probar: el pulido varía por entorno. React 19 está excelente, con Server Components en modo experimental. Svelte 5 es sólido, Solid es bueno, Vue 3 funciona bien pero tiene casos de borde con directivas personalizadas y Lit es adecuado pero menos cuidado. Cuando conviven dos o más entornos, algunos patrones solo funcionan bien en uno, así que un único entorno de interfaz por proyecto simplifica la experiencia.

Fuentes

  1. Anuncio oficial de Astro 5.0 en el blog de Astro
  2. Content Collections y la Content Layer API, documentación de Astro
  3. Server Islands, documentación de Astro
  4. Notas de la versión astro@5.0.0 en GitHub