Casos de uso de las server islands
Dónde brillan de verdad: personalización por usuario —saludo, carrito, menú de cuenta— sin renunciar al caché; datos frescos que cambian más rápido que el ritmo del build —precio, stock, contadores en vivo—; y, sobre todo, la página entera cacheada en el CDN mientras sus trozos variables laten a su propia cadencia. Pensar una página como una composición de tiempos de vida de caché.
Personalización sin sacrificar el caché
El caso canónico. Todo lo que depende de quién mira es candidato a server island: el saludo con el nombre, el avatar, el menú que alterna entre Iniciar sesión y el panel de cuenta, el contador del carrito, los “vistos recientemente”, las recomendaciones.
Como la petición de la isla lleva las cookies del navegador, la isla lee la sesión y personaliza con total conocimiento de quién eres, sin que la página anfitriona deje de ser un fichero estático compartido por todos.
---import MenuUsuario from '../components/MenuUsuario.astro';---<MenuUsuario server:defer> <a slot="fallback" href="/login">Iniciar sesión</a></MenuUsuario>La página que aloja ese menú puede prerenderizarse y servirse desde el CDN a un millón de visitantes idénticos; solo el recuadro del menú se resuelve por persona. La personalización deja de ser el enemigo del caché.
Y fíjate en la elegancia del fallback: Iniciar sesión es exactamente lo que verá quien no ha iniciado sesión, así que para la mayoría de visitantes anónimos la isla ni siquiera cambia nada visible, y para los registrados se refina a su menú.
Datos frescos por encima del ritmo del build
El segundo eje no es quién mira, sino cuándo. Hay datos que cambian más deprisa de lo que tú reconstruyes el sitio: el precio en un mercado que se mueve, el stock que baja con cada compra, un contador de “personas viendo esto ahora”, un marcador deportivo, la disponibilidad de una sala.
Hornear ese dato en el build lo deja obsoleto en minutos; renderizar toda la página por petición para refrescarlo tira el caché de todo lo demás.
Una server island resuelve el fragmento en el instante de la visita, así que el dato es tan fresco como el momento en que lo pides, mientras el resto de la página —la descripción, las fotos, las reseñas— sigue horneado y cacheado.
La cadencia de reconstrucción del sitio deja de imponerle un techo a la frescura de sus partes más volátiles.
Entre esos casos, el tercero merece un apunte. Un test A/B o un feature flag son, en el fondo, personalización por cohorte en vez de por individuo: la isla decide qué variante mostrar según una cookie o una regla, y el cascarón permanece idéntico para todos.
Igual ocurre con el contenido por región —un banner distinto según el país detectado— o por idioma. En todos ellos, la variabilidad se concentra en un recuadro y no obliga a duplicar ni a descachear la página.
La página entera en el CDN
Aquí está el beneficio que engloba a los demás. Una ficha de producto de comercio electrónico es el ejemplo perfecto: su cuerpo cambia rara vez, su precio cada pocos minutos, su cabecera con cada visitante.
Con server islands, el cascarón se cachea en el borde y late al ritmo lento del contenido, mientras el precio y el menú se resuelven por petición.
---import MenuUsuario from '../components/MenuUsuario.astro';import PrecioEnVivo from '../components/PrecioEnVivo.astro';const { producto } = Astro.props; // datos horneados en el build---<MenuUsuario server:defer> <a slot="fallback" href="/login">Iniciar sesión</a></MenuUsuario><h1>{producto.nombre}</h1><p>{producto.descripcion}</p><PrecioEnVivo id={producto.id} server:defer> <span slot="fallback">Consultando precio…</span></PrecioEnVivo>Fíjate en un detalle de la última isla: a PrecioEnVivo se le pasa solo id, no el precio. La isla, al renderizarse, consultará el precio del momento con ese identificador. El cascarón sabe qué producto es; la isla averigua cuánto cuesta ahora.
Esa división de responsabilidades es la que mantiene la página cacheable y el precio vivo, y anticipa una regla de la próxima lección: pasa identificadores, no volúmenes.
Repara también en que en esta única página conviven dos islas con cadencias distintas —el menú por usuario, el precio por minuto— y un cascarón perenne con el título y la descripción. Tres ritmos, una URL, un solo documento cacheable.
Eso, que hace dos años exigía elegir entre un sitio rápido y un sitio fresco, ahora es la configuración por defecto de una buena ficha de producto.
Cuándo una isla gana a un fetch de cliente
La alternativa obvia a una server island es ir a buscar el dato con JavaScript desde el navegador. A veces esa es la opción correcta —cuando el dato es realmente interactivo y cambia tras acciones del usuario—, pero para pintar un fragmento dinámico en la carga, la server island suele ganar.
Renderiza en el servidor, así que no expones un endpoint público que mantener y proteger, no sufres una cascada de “cargar JS, luego pedir datos, luego pintar”, no lidias con CORS ni con secretos en el cliente, y estás más cerca de la base de datos.
El fragmento llega ya como HTML, no como un esqueleto que el cliente tiene que rellenar.
Por qué la isla suele ganar para pintar:
- Sin API pública: no expones un endpoint que autenticar, limitar y validar.
- Sin cascada: el HTML llega servido, no tras cargar JS y luego pedir datos.
- Más cerca del dato: corre en el servidor, sin CORS ni secretos en el cliente.
Hay además una diferencia de superficie de ataque que a veces se pasa por alto. Un fetch de cliente obliga a publicar una API con la que cualquiera puede hablar, así que tienes que autenticarla, limitarla y validarla como cualquier endpoint expuesto.
Una server island no publica nada: su único punto de entrada es el endpoint interno de Astro, y sus argumentos viajan sellados. Mueves lógica sensible del cliente al servidor sin abrir una puerta nueva al mundo.