Islas de Astro y el coste del JavaScript
La página mediana envió 632 KB de JavaScript a móvil en 2025. La arquitectura de islas convierte esa cifra en una decisión y no en un valor por defecto, siempre que alguien mida el bundle tras cada release.
Contenido
La arquitectura de islas renderiza la página como HTML estático e hidrata solo los componentes marcados como interactivos. En Astro esa marca es una directiva client:*, y el valor por defecto es cero JavaScript. El payload pasa a ser una decisión por componente, no del framework, y de ahí sale el ahorro.
Puntos clave
- La home mediana en móvil envió 632 KB de JavaScript en 2025, frente a 911 KB de imágenes y un total de 2,56 MB, según el Web Almanac de HTTP Archive.
- Los componentes de Astro se renderizan a HTML sin runtime de cliente. El JavaScript se envía solo con una directiva
client:*. - La directiva es la decisión:
client:load,client:idle,client:visible,client:mediayclient:onlyhidratan en momentos distintos y cuestan hilo principal distinto. - El 77 % de los orígenes móviles tuvo buen INP en 2025 frente al 97 % en escritorio, y el Total Blocking Time de laboratorio subió un 58 % interanual.
- Las islas reducen los bytes enviados, no el trabajo dentro de una isla. Una sola isla sobredimensionada puede arruinar el INP.
Qué envió la página mediana en 2025
El Web Almanac de 2025, publicado el 15 de enero de 2026, midió la home mediana en 2,86 MB en escritorio y 2,56 MB en móvil. El JavaScript fue el segundo recurso por peso, tras las imágenes.
El Web Almanac de HTTP Archive registró que la home mediana en móvil usó en 2025 632 KB de JavaScript, 911 KB de imágenes y 122 KB de fuentes. La mediana de escritorio fue de 697 KB de JavaScript y 1.058 KB de imágenes (HTTP Archive, enero de 2026).
De ahí salen dos consecuencias. El JavaScript es el recurso que más depende del equipo, porque una imagen la comprime el build y una librería de componentes no. Y un móvil mediano parsea y ejecuta esos 632 KB antes de responder a un toque.
Qué cambian las islas
Un componente de Astro se renderiza a HTML estático y no envía runtime de cliente. Uno de React, Vue o Svelte dentro de una página Astro también se renderiza a markup, y su JavaScript se elimina salvo que una directiva pida hidratación.
Eso invierte el valor por defecto habitual. En una single-page application se hidrata el árbol entero y se sale de ahí con code splitting. Con islas no se hidrata nada y se entra componente a componente. La decisión es la misma, pero ahora la respuesta segura es la barata. Es el argumento detrás de elegir el stack por restricción y no por costumbre: el framework hace del resultado deseado el camino de menor esfuerzo.
Elegir directiva es una decisión de medición
Astro documenta cinco directivas de cliente. client:load hidrata de inmediato y client:idle espera a que el navegador quede inactivo. client:visible espera a que el componente entre en el viewport, client:media hidrata al coincidir una media query y client:only se salta el renderizado en servidor.
Por defecto, `client:visible`, y justifica cualquier cosa más ansiosa. Un buscador desplegable en la cabecera puede ser client:load. Un acordeón del pie, un mapa, un carrusel o un widget de comentarios son client:visible, y esa diferencia es trabajo real fuera de la ventana inicial del hilo principal.
client:only merece desconfianza. Envía el componente y no renderiza nada en servidor, así que su contenido es invisible para los crawlers y antes de la hidratación. Sirve para widgets que no pueden renderizarse sin API del navegador, no para silenciar un desajuste.
Qué conviene dejar estático
Casi todo un sitio de marketing es texto, imágenes y enlaces, y nada de eso necesita hidratación. La navegación puede ser HTML y CSS. Los acordeones pueden ser <details>. La validación puede empezar por la constraint validation API y añadir JavaScript solo para lo que el HTML no expresa.
Los elementos nativos llegan además con el comportamiento de teclado y el estado anunciado correctos, lo que elimina defectos que la Ley Europea de Accesibilidad vuelve caros de mantener.
Las server islands cubren lo personalizado
La objeción habitual a la salida estática es la personalización: contador del carrito, nombre de la sesión, precio por región. Astro 5.0, publicado el 3 de diciembre de 2024, dejó estables las server islands. Un componente con server:defer renderiza un fallback dentro de la página cacheada y pide su contenido bajo demanda.
La página sigue siendo cacheable y una isla lenta no bloquea al resto. Es una estrategia de renderizado, no de hidratación, y elimina el motivo más común por el que un equipo abandona la salida estática.
Medir lo que realmente se envía
Las islas facilitan creer que el bundle es pequeño. Conviene medirlo igualmente, cada release.
Se siguen cuatro números por plantilla: JavaScript transferido, islas hidratadas, Total Blocking Time en laboratorio e INP de campo en el percentil 75. El INP considera buena una interacción de 200 ms o menos, sumando input delay, procesamiento y presentation delay.
El Web Almanac de 2025 encontró un 77 % de orígenes móviles con buen INP frente a un 97 % en escritorio. El Total Blocking Time de laboratorio subió un 58 % respecto a 2024: más ejecución, repartida de forma desigual por clase de dispositivo (HTTP Archive, enero de 2026).
Un presupuesto solo sirve si tumba un build. Se fija un techo por ruta en kilobytes, se conecta a la CI y el incumplimiento se trata como un test que falla.
Preguntas frecuentes
¿Astro hace rápido un sitio por sí solo?
No. Quita el JavaScript que nadie pidió y deja el resto en tus manos. Una página con seis islas ansiosas, un hero sin optimizar y un tag manager con tres proveedores será lenta en cualquier framework. Los valores por defecto ayudan; las mediciones deciden.
¿Cuántas islas son demasiadas?
No hay número fijo: el coste depende de lo que haga cada isla. La prueba práctica es el Total Blocking Time en laboratorio y el INP en campo. Si alguno empeora tras un release, mira la última isla añadida y lo que importa.
¿Las islas ayudan al LCP?
De forma indirecta. El LCP lo decide la imagen del hero y la cadena de peticiones críticas, no la hidratación, así que siguen valiendo las correcciones de qué mueve de verdad el LCP. Las islas ayudan sobre todo a las métricas de respuesta, manteniendo libre el hilo principal.
¿Este enfoque sobrevive a un rediseño?
Sí, si el modelo de contenido está separado de los componentes. La decisión de hidratación vive en la plantilla; el contenido vive en el CMS. Es la misma disciplina que modelar contenido para que sobreviva a un rediseño y que mantener los design tokens como contrato entre diseño y código.
Empieza listando cada componente que envía JavaScript y pregunta qué se rompe sin él. Convierte a markup estático las respuestas honestas, mueve el resto a client:visible y reserva la hidratación ansiosa para los primeros segundos. Después fija un presupuesto por ruta y deja que tumbe builds. Dentro de seis meses la pregunta será si los equipos lo aguantaron tras la tercera petición de funcionalidad. Eso, y no el framework, decide lo que descarga un usuario.
