Astro v5: La Bestia Actual de las Webs

Astro es hoy una de las bestias del ecosistema web: el framework pensado para sitios orientados a contenido —blogs, marketing, e-commerce— que cargan rápido y tienen excelente SEO. Con Astro 5.0 (lanzado en diciembre de 2024) el framework da un salto grande: Content Layer para traer contenido de cualquier fuente, Server Islands para mezclar HTML estático con contenido dinámico y personalizado en la misma página, y una simplificación importante de cómo conviven SSG (static site generation) y SSR (server-side rendering). En la práctica, son hermanos: estático por defecto, y servidor cuando lo necesitas.

Mi portfolio está hecho al 100% en Astro vanilla (sin React, Vue ni Svelte en el cliente) y uso Astro en muchos de mis proyectos. En este artículo repaso qué es Astro, qué trae v5 y todo lo que puedes hacer con él.

¿Qué es Astro?

Astro es el framework web para construir sitios orientados a contenido: blogs, landing pages, marketing, e-commerce. Si necesitas un sitio que cargue rápido y con buen SEO, Astro encaja muy bien.

Sus pilares:

Zero JS por defecto: Astro envía HTML y CSS; el JavaScript que añades es opt-in (islands). Menos JS = menos peso y mejor tiempo de carga.
Islands Architecture: Solo los componentes que necesitan interactividad se hidratan; el resto queda estático. Menos trabajo en el navegador.
Multi-framework (opcional): Puedes usar React, Vue, Svelte, Solid, etc. solo donde haga falta, o quedarte en Astro vanilla como en mi portfolio: componentes .astro, algo de JS en el cliente si lo necesitas, y listo.
SSG y SSR: Por defecto genera HTML estático en build time. Si añades un adaptador de servidor (Node, Vercel, Netlify, Cloudflare), puedes tener rutas renderizadas on-demand en el servidor.

Con v5, Astro refuerza todo esto y añade herramientas nuevas para contenido y para mezclar estático y dinámico en la misma página.

Astro 5.0: Lo que trae

Content Layer (capa de contenido)

Astro siempre ha sido fuerte en contenido. Con Content Layer en v5, las content collections pasan a ser una capa unificada y tipada donde el contenido puede venir de cualquier sitio: Markdown en disco, CMS (Notion, Storyblok, Hygraph, etc.), APIs REST o sistemas de assets.

Loaders: Funciones que obtienen y transforman datos. Puedes usar loaders built-in (por ejemplo glob para archivos) o definir los tuyos (una API, un CMS).
Una sola API: Defines colecciones en content.config.ts y las usas en las páginas con tipos y autocompletado.
Rendimiento: En v5, las colecciones de Markdown pueden construir hasta 5x más rápido en sitios con mucho contenido, y hasta 2x más rápido para MDX, con menos uso de memoria.

Así puedes tener blog en Markdown, datos de un CMS y datos de una API en el mismo sitio, todo tipado y cacheado en build time.

Server Islands (islas en el servidor)

Las islands en el cliente (solo hidratar lo necesario) ya eran la seña de Astro. En v5 llegan las Server Islands: la misma idea pero en el servidor. Puedes tener en una misma página:

Contenido estático que no cambia (cacheado en CDN).
Contenido dinámico generado en el servidor (base de datos, usuario logueado).
Contenido personalizado (avatar, carrito, reseñas) que se genera on-demand.

Antes tenías que elegir una estrategia de cache para toda la página. Con Server Islands, la página base puede estar muy cacheada y solo las “islas” dinámicas (con server:defer) se renderizan cuando hace falta. Cada isla se carga de forma independiente: una isla lenta no bloquea el resto.

Esto permite páginas que cargan al instante desde el edge y solo las partes personalizadas se rellenan después. Para usar Server Islands necesitas un adaptador de servidor (Node, Vercel, Netlify, Cloudflare).

SSG y SSR: Hermanos, no enemigos

En Astro, SSG (static site generation) y SSR (server-side rendering) son hermanos: el mismo framework, dos modos de salida.

Por defecto: estático (SSG). Astro pre-renderiza las páginas en build time y genera HTML estático. Rápido, cacheable, ideal para contenido que no cambia en cada request.
Cuando lo necesitas: servidor (SSR). Añades un adaptador (por ejemplo @astrojs/node, @astrojs/vercel) y marcas rutas con prerender = false. Esas rutas se renderizan on-demand en el servidor.

En v5 se simplifica la configuración: el modo híbrido se fusiona con el estático. Ya no eliges output: "hybrid"; usas output: "static" (por defecto) y, si en alguna ruta pones prerender = false, Astro usa SSR solo para esa ruta. No hace falta acordarse de una matriz de modos: estático por defecto, servidor donde lo marques.

Resumen: SSG para la mayoría de las páginas; SSR para login, dashboards, contenido por usuario o por request. Mismo proyecto, misma mentalidad.

astro:env (variables de entorno tipadas)

En v5, astro:env permite definir variables de entorno de forma tipada y segura:

Indicar si una variable es de cliente o servidor.
Marcar variables como secret (claves API, etc.) para que no se expongan en el cliente ni se incrusten en el build del servidor.
Definir si son requeridas u opcionales y el tipo (string, number, boolean, enum).

Se configuran en astro.config.mjs y se importan donde las necesites, por ejemplo import { STRIPE_API_KEY } from 'astro:env/server', con tipos y validación antes de arrancar.

Vite 6

Astro 5 corre sobre Vite 6. Para la mayoría de proyectos no cambia nada en tu código; el beneficio es un dev server y un build más alineados con cómo se ejecuta el código en producción. A largo plazo, esto permite mejor soporte para entornos como Cloudflare o runtimes edge.

Experimental: imágenes responsivas y SVG como componente

En v5 hay flags experimentales útiles:

Responsive images: Recorte con fit y position, y layouts responsivos que generan srcset y sizes correctos.
SVG como componente: Importas un .svg y lo usas como componente Astro, pasando width, height, fill, stroke, etc.

Habilitables en astro.config.mjs con experimental.responsiveImages y experimental.svg.

Qué puedes hacer con Astro (resumen)

Sitios estáticos puros (SSG): Blogs, documentación, landings. Cero servidor si quieres; despliegue en cualquier hosting estático.
Sitios híbridos: La mayoría de rutas estáticas, algunas SSR (formularios, auth, contenido por usuario).
Contenido desde muchas fuentes: Markdown, CMS, APIs, con Content Layer y loaders.
Performance y SEO: Poco JS por defecto, HTML estático, islands solo donde haga falta.
Astro vanilla: Como en mi portfolio: solo .astro, Tailwind (o el CSS que prefieras), sitemap, sin frameworks de UI en el cliente. Opcionalmente añades React/Vue/Svelte solo donde lo necesites.

Mi portfolio: 100% Astro vanilla

Este portfolio (sebastiancheikh.com) está hecho íntegramente en Astro vanilla. No hay React, Vue ni Svelte en el bundle del cliente. Uso:

Componentes .astro para layout, secciones y páginas.
Content collections para el blog (Markdown por idioma).
Tailwind para estilos.
@astrojs/sitemap para el sitemap.
Build estático (SSG); despliegue en un servidor o CDN.

Es rápido, fácil de mantener y demuestra que para muchos sitios no hace falta un framework pesado en el cliente. Además, uso Astro en muchos de mis proyectos: desde sitios corporativos hasta blogs y landings, por la misma razón: menos complejidad, mejor rendimiento, mismo DX agradable.

Mi perspectiva personal

Astro v5 consolida lo que ya hacía bien Astro (rápido, poco JS, SSG/SSR claro) y añade Content Layer y Server Islands para sitios más complejos sin dejar de ser simple cuando no los necesitas. La unificación de “estático + servidor cuando lo pidas” sin modos híbridos confusos me parece un acierto.

Para portfolios, blogs, documentación y sitios de contenido, Astro sigue siendo mi primera opción. Si en el futuro necesito interactividad localizada, puedo añadir una isla en React o Vue sin reescribir todo. Si no, me quedo en vanilla y el sitio sigue siendo una bestia de rendimiento.

Si quieres probar Astro 5: npm create astro@latest. Si ya tienes un proyecto, la guía oficial es Astro v5.Y si quieres ver un ejemplo real en Astro vanilla, este portfolio es uno.