La arquitectura de islas explicada

“Islands architecture” es el nombre del patrón que sostiene todo lo demás. La idea, popularizada por Jason Miller en 2020, es simple y potente: renderiza la página como HTML estático y siembra en ella pequeñas regiones interactivas —islas— que se hidratan de forma independiente. Entender por qué esa independencia lo cambia todo es entender Astro.

El océano de HTML y las islas

La metáfora es literal. La mayor parte de una página de contenido es un mar de HTML estático —cabeceras, párrafos, imágenes, enlaces— que no necesita JavaScript. Salpicadas en ese mar hay unas pocas regiones que sí lo necesitan: un buscador, un widget de comentarios, un selector de tema. Cada una de esas regiones es una isla: un componente interactivo, autónomo, rodeado de contenido inerte.

En una SPA no hay islas ni mar: todo es aplicación. La página es un único árbol de componentes con una sola raíz, y esa raíz gobierna hasta el último párrafo de texto. En Astro, la relación se invierte: el HTML es el continente y la interactividad son excepciones acotadas dentro de él. El patrón no lo inventó Astro —Katie Sierra Hanson lo describió antes y Jason Miller le puso nombre—, pero Astro fue el primero en construir un framework entero alrededor de la idea, en lugar de tratarla como una optimización opcional.

Hidratación parcial: solo lo que hace falta

La primera propiedad clave es la hidratación parcial. En lugar de hidratar el documento entero, Astro hidrata únicamente los nodos marcados como islas. Si tu página tiene un buscador y cincuenta párrafos, solo se envía y ejecuta el JavaScript del buscador. Los cincuenta párrafos jamás participan en la hidratación porque nunca fueron JavaScript: nacieron y murieron como HTML.

---
import Contador from '../components/Contador.jsx';
---
<h1>Un artículo largo</h1>
<p>Miles de palabras de HTML puro, sin coste de hidratación...</p>

<!-- La unica parte que envia y ejecuta JS es esta isla -->
<Contador client:load />

<p>...y sigue el HTML puro despues de la isla.</p>

La consecuencia es directa sobre las métricas del nivel 1.1: el TBT se desploma porque el hilo principal apenas tiene trabajo que hacer. No hay un árbol gigante que reconstruir, solo una isla diminuta que activar. Y como cada isla se empaqueta por separado, el JavaScript total de la página es la suma de sus islas, no un bundle monolítico: pagas exactamente por lo que declaras, ni un byte más.

El patrón produce cuatro efectos encadenados y todos medibles:

• Menos bytes: solo viaja el JavaScript de las islas, no un framework para toda la página.
• Menos bloqueo: el hilo principal hidrata unos pocos nodos, no un árbol entero.
• Mejor TTI: la página responde en cuanto arranca la primera isla, no cuando termina la última.
• Degradación elegante: si una isla falla, el resto del documento sigue en pie.

Hidratación independiente: cada isla, su propia raíz

La segunda propiedad, más sutil y más importante, es la independencia. Cada isla es una raíz de hidratación separada, con su propio fragmento de runtime y su propio ciclo de arranque. Las islas no comparten un árbol ni un scheduler común: se hidratan en paralelo y sin bloquearse entre sí.

Esto rompe el punto débil de la SPA. En una SPA la hidratación es todo-o-nada y de arriba abajo: hay una sola raíz, se reconstruye el árbol completo en una pasada, y si una sola parte es pesada, la interactividad de toda la página espera. Un widget lento contamina a todos los demás. En Astro, una isla pesada que tarda en hidratar no impide que una isla ligera de al lado responda de inmediato: son procesos aislados que arrancan cuando les toca.

flowchart TB
subgraph SPA[SPA: hidratacion todo o nada]
  R[Raiz unica] --> N1[Nav]
  R --> N2[Articulo]
  R --> N3[Comentarios]
  R --> N4[Footer]
end
subgraph ISLAS[Astro: islas independientes]
  H[Oceano de HTML estatico]
  H --- I1[Isla buscador]
  H --- I2[Isla comentarios]
end
style R fill:#f38ba8,color:#11111b
style H fill:#a6e3a1,color:#11111b
style I1 fill:#89b4fa,color:#11111b
style I2 fill:#89b4fa,color:#11111b

Ese aislamiento tiene un matiz que conviene saber pronto: como cada isla es su propia raíz, no comparten estado de forma automática. Los datos que pasas del servidor a una isla como props se serializan una vez, en el build o la petición, y quedan congelados dentro de esa isla. Si dos islas deben comunicarse en el cliente, se usa un almacén ligero compartido —por ejemplo, nanostores— o eventos del navegador, no el estado interno de un árbol común que aquí sencillamente no existe.

Cuándo se hidrata: las estrategias de carga

La independencia también gobierna el cuándo. Cada isla decide su momento de hidratación con su directiva, y todas conviven en la misma página sin coordinarse. Elegir bien la directiva es la palanca principal de rendimiento que tendrás en tus manos.

En la práctica, conviven en el mismo archivo, cada una con su estrategia declarada al lado del componente:

---
import Tema from '../components/Tema.jsx';
import Menu from '../components/Menu.svelte';
import Comentarios from '../components/Comentarios.jsx';
---
<Tema client:load />                          <!-- critico: hidrata ya -->
<Menu client:media="(max-width: 768px)" />    <!-- solo en movil -->
<Comentarios client:visible />                <!-- al llegar con el scroll -->

Hay una quinta, client:media, que hidrata solo si se cumple una media query: perfecta para un menú que únicamente existe en móvil, evitando cargar su JavaScript en escritorio. Y en 2026 el patrón se ha extendido al servidor con las server islands, que difieren la generación de un fragmento dinámico a una petición aparte, dejando el resto de la página cacheable como estático. La misma idea —aislar lo variable de lo estable— aplicada ahora en las dos direcciones.

Qué merece de verdad ser isla

No todo lo interactivo necesita serlo. Una buena isla suele cumplir algo de esto:

• Mantiene estado propio que cambia con el tiempo: un contador, un formulario, un filtro.
• Reacciona a eventos más allá de un enlace: arrastrar, alternar, buscar mientras escribes.
• Necesita el navegador para existir: un mapa, un canvas, un reproductor de vídeo.

Si algo se resuelve con un enlace, con un elemento nativo de HTML o con una animación de CSS, no es una isla: es contenido con estilo, y debe quedarse como HTML puro.