Astro y las islas: la web que envía menos JavaScript

Actualizado: 2026-05-03

Durante una década, el reflejo por defecto al arrancar cualquier sitio web nuevo ha sido abrir Next.js, Gatsby o una SPA con Create React App y empezar a escribir componentes. El resultado es conocido: un blog de diez páginas termina enviando doscientos kilobytes de JavaScript al cliente para renderizar un texto que podría haberse servido como HTML plano en un décimo del tiempo. Astro nace precisamente contra ese reflejo. Su premisa es brutalmente simple: si el noventa por ciento de tu página es contenido estático, deberías enviar HTML estático y reservar el JavaScript solo para los trozos que de verdad lo necesitan.

Puntos clave

• Astro envía cero JavaScript por defecto; el bundle crece solo con el número de islas interactivas, no con el tamaño de la aplicación.
• Las directivas de cliente (client:load, client:visible, client:idle) dan control granular sobre cuándo se hidrata cada componente.
• Para blogs, documentación, marketing sites y e-commerce centrado en contenido, los números de rendimiento son consistentemente mejores que Next.js SSG o Gatsby.
• Astro acepta componentes de React, Vue, Svelte, Solid y Preact en el mismo proyecto, lo que facilita la migración incremental.
• No es la elección correcta para aplicaciones donde la interactividad es el producto: paneles SaaS, editores colaborativos, apps con estado compartido entre rutas.

Qué cambia con las islas

La arquitectura de islas reordena el modelo mental. En una SPA clásica todo el árbol de componentes vive en el cliente, y el servidor entrega un shell vacío que React hidrata tras cargar el bundle. En un framework SSR tradicional como Next.js o Remix el servidor renderiza el HTML, pero luego hidrata el árbol completo para que cualquier componente pueda volverse interactivo. Astro rompe ese contrato: el servidor renderiza HTML, y la hidratación es opt-in por componente. Cada componente interactivo es una isla autónoma que se hidrata sola, con su propio runtime, sin arrastrar al resto de la página.

La consecuencia práctica: el bundle de JavaScript deja de ser función del tamaño de la aplicación y pasa a ser función del número de islas. Un blog con cabecera estática, artículo estático, footer estático y un único buscador React acaba enviando solo el runtime de React más el código del buscador. No hay hidratación del artículo, no hay reconciliación del footer, no hay árbol de componentes vivo esperando eventos. Es HTML, y ya está.

Directivas de cliente: control sobre la hidratación

Donde Astro se vuelve especialmente fino es en el control de cuándo se hidrata cada isla:

• client:load: hidrata en cuanto la página termina de cargar. Para elementos críticos como carrito o selector de idioma.
• client:idle: difiere la hidratación hasta que el navegador tiene ciclos libres. Ideal para widgets secundarios.
• client:visible: espera a que el componente entre en viewport antes de cargar su JavaScript. Un carrusel below-the-fold es gratis hasta que alguien hace scroll.
• client:media: condiciona la hidratación a una media query. Un menú móvil que solo se hidrata en móvil.
• client:only: salta el renderizado del servidor por completo. Para componentes que dependen de APIs exclusivas del navegador.

Este control granular permite que un sitio tenga decenas de componentes potencialmente interactivos pero solo cargue tres o cuatro en la primera interacción.

Content Collections y el modelo de contenido

A partir de Astro 2.0, el framework incorpora content collections con esquemas validados por Zod. Declaras una colección en content/config.ts, defines el schema del frontmatter, y el resto del proyecto obtiene tipado estricto sobre cada post:

// content/config.ts
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string()),
  })
});

export const collections = { blog };

Si el frontmatter de un archivo incumple el schema, el build falla con un mensaje claro. getCollection('blog') devuelve posts tipados. Comparado con el sistema de getStaticProps de Next.js o el gatsby-node.js de Gatsby, esto es refrescantemente directo.

Rendimiento medido: dónde gana y cuánto

En un blog de tamaño medio, los números son consistentes. El bundle de JavaScript baja de rangos de 100-200 KB (Next.js SSG, Gatsby) a 2-10 KB. El Time To Interactive cae de 1,5 segundos a alrededor de 300 ms. El Largest Contentful Paint se reduce de más de un segundo a medio segundo. Lighthouse marca 100 en performance sin esfuerzo. Estos números son lo que sale cuando la página literalmente no tiene JavaScript que ejecutar.

La honestidad exige matizar: esas cifras son para sitios donde el contenido domina. Un dashboard con gráficos, filtros, tablas reactivas y estado compartido entre vistas no gana nada moviéndose a Astro; si acaso complica la arquitectura.

Cuándo elegirlo y cuándo no

Astro brilla en:

• Blogs, documentación, marketing sites, portfolios.
• Landing pages de producto y e-commerce centrado en contenido.
• Cualquier caso donde la interactividad se limite a buscadores, carritos y filtros simples.

Pierde claramente en:

• Paneles SaaS con estado complejo.
• Herramientas colaborativas en tiempo real.
• Apps con navegación tipo SPA y estado compartido entre rutas.
• Clientes de chat en tiempo real.

La arquitectura de islas asume que las islas son pocas y relativamente independientes. Cuando cada página es una isla gigante con estado compartido, el modelo se rompe. Para esos casos, HTMX puede ser un punto intermedio interesante si el equipo es pequeño y el backend es expresivo.

Despliegue y portabilidad

Astro compila a output estático por defecto, hosteable en cualquier CDN: Netlify, Vercel, Cloudflare Pages, GitHub Pages, un bucket S3 detrás de CloudFront. Con el adapter correcto puede emitir SSR para Node, Deno, Cloudflare Workers o Vercel. El modo híbrido permite mezclar rutas estáticas y SSR en el mismo proyecto.

Astro 3.0 añadió View Transitions nativas, que dan transiciones tipo SPA entre páginas usando la API del navegador sin coste adicional de JavaScript. La sensación es de aplicación fluida sobre una base estática.

Conclusión

La conversación sobre frameworks web lleva años dominada por la pregunta equivocada: ¿qué framework React usar? Astro la reformula: ¿cuánto React necesitas realmente? Para la mayoría de sitios content-heavy que pueblan la web, la respuesta honesta es “muy poco, y solo en sitios concretos”. Astro convierte esa observación en arquitectura por defecto, y el resultado son sitios más rápidos, más baratos de mantener y más fáciles de servir. No es una bala de plata — su autor, Fred K. Schott, ha sido explícito en que Astro no quiere reemplazar Next.js para aplicaciones. Para todo lo demás, que es la mayor parte de la web, ofrece un camino más sensato que llevar React a cada esquina.