Astro es el framework que ha popularizado la arquitectura de islas en el desarrollo de webs corporativas: en vez de cargar un framework de JavaScript completo en cada página, renderiza HTML y CSS estáticos y solo añade interactividad donde el usuario la necesita de verdad. Según los datos de uso que recopila W3Techs, todavía es minoritario frente a WordPress o Next.js, pero ya lo usan sitios como Cloudflare o Python.org. Para un equipo que decide con qué construir la web de la empresa, la pregunta no es si Astro es mejor en abstracto, sino en qué tipo de sitio compensa.
Astro reduce el JavaScript que llega al navegador porque no envía ninguno por defecto: cada página se genera en HTML y CSS, y solo los componentes marcados con una directiva de cliente se hidratan después en el navegador. Según la documentación oficial del proyecto, ese es el principio de la arquitectura de islas: hidratación selectiva, no total.
La arquitectura de islas cambia el desarrollo web
La mayoría de frameworks de JavaScript modernos hidratan toda la página en el navegador, aunque buena parte del contenido sea texto estático que no necesita interactividad alguna. Astro invierte ese planteamiento: compila cada página a HTML y CSS, y solo convierte en isla los fragmentos que de verdad necesitan ejecutarse en el cliente, como un formulario de contacto, un buscador interno o un carrusel de proyectos.
La documentación oficial de Astro lo resume así: el framework genera cada sitio con cero JavaScript del lado del cliente por defecto, y es el equipo de desarrollo quien decide, componente a componente, cuál necesita hidratarse y con qué directiva. Esa decisión explícita es la diferencia real frente a un framework que hidrata de serie toda la página.
Para una web corporativa, donde la mayor parte de las páginas son contenido —servicios, blog, ficha de empresa— y solo unas pocas piezas son interactivas, ese reparto suele traducirse en menos JavaScript cargado y menos trabajo para el navegador en el primer pintado de la página.
La arquitectura de islas es un patrón de diseño frontend en el que la mayor parte de una página se sirve como HTML estático y solo fragmentos aislados —las islas— se hidratan con JavaScript para ser interactivos, en lugar de cargar un framework completo para pintar toda la página.
Cuándo conviene Astro frente a Next.js
Next.js no compite con Astro en islas: es un framework pensado para aplicaciones, con renderizado híbrido y rutas de API propias. La pregunta no es cuál de los dos es superior, sino qué proporción de la web necesita estado de aplicación.
Astro para la web con poca interactividad
Una web corporativa, un blog, una landing de servicios o un catálogo sin carrito propio son los casos donde Astro rinde mejor: la mayoría de páginas no cambian según quién las visita, así que no hay razón para enviar un framework entero al navegador para pintar un título y un párrafo. El equipo sigue pudiendo usar React, Vue o Svelte para los componentes que sí lo necesiten —un formulario, un configurador, un widget de reservas— sin que el resto de la página pague ese coste. El resultado práctico es un sitio que carga rápido incluso en una conexión móvil mediocre.
Next.js cuando el sitio funciona como aplicación
Un portal de cliente con inicio de sesión, un panel con datos en tiempo real o un ecommerce con carrito y checkout propio necesitan estado, sesiones y rutas que reaccionan al usuario: ahí Next.js da más por su arquitectura de aplicación que por su velocidad de carga inicial. El App Router, el renderizado en el servidor por petición y las rutas de API en el mismo proyecto resuelven problemas que Astro no está pensado para resolver sin añadir otra capa encima.
Cada isla admite un framework de componentes distinto
Astro no obliga a elegir un único framework de interfaz: cada isla puede escribirse con el que ya domine el equipo, y es habitual mezclar varios en el mismo proyecto durante una migración progresiva. Los más usados en producción son estos:
- React, para reutilizar componentes de un proyecto existente.
- Vue, frecuente en equipos que vienen de un frontend ya construido con Vue.
- Svelte, cuando el peso final de la isla importa más que el ecosistema disponible.
- Solid y Preact, para interactividad mínima con el menor JavaScript posible.
Esa flexibilidad tiene un coste de mantenimiento: cada framework añadido suma su propia dependencia, su ciclo de actualizaciones y una curva de aprendizaje distinta para quien toque el código después. Un equipo que empieza de cero rara vez necesita más de uno; mezclar varios solo compensa cuando ya hay componentes hechos en frameworks distintos.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Cuánto JavaScript llega realmente al navegador
La cifra que más circula sobre Astro es la del JavaScript que no envía, pero conviene matizarla: una página cien por cien estática no manda ninguno, y una página con varias islas puede acabar enviando un peso similar al de un framework convencional si cada isla carga su propio runtime sin compartirlo con las demás. El peso final es proporcional a la interactividad real de la página, no al tamaño del framework completo, y eso es lo que de verdad acerca una página a cumplir los umbrales de Core Web Vitals en la franja «buena».
Esto conecta con una decisión que ya se plantearon muchas webs corporativas al valorar los Web Components como alternativa a React: cuanto menos runtime de framework viaje al navegador, menos depende el tiempo de carga de la librería elegida. Medirlo página a página con las herramientas de rendimiento del navegador, y no de memoria, es el único modo fiable de decidir si una migración compensa.
Astro combinado con un CMS headless real
Astro no incluye gestor de contenidos propio, así que en un proyecto corporativo suele ir conectado a un CMS headless que entrega el contenido por API mientras Astro se encarga solo de pintarlo. Esa separación es la misma que ya se analizó al comparar cuatro plataformas de CMS headless y lo que cuesta cada una: el framework de frontend y el gestor de contenido son decisiones independientes, y combinar Astro con el CMS que ya paga la empresa suele costar menos que migrar los dos a la vez.
La ventaja para un equipo de marketing es que el flujo editorial no cambia: quien escribe sigue entrando al mismo panel, y es el equipo de desarrollo quien decide cómo se consume esa API. El riesgo habitual es subestimar el trabajo de integración.
Qué equipo mantiene un sitio hecho con islas
Astro reduce el JavaScript que llega al navegador, pero no reduce el trabajo de desarrollo: sigue haciendo falta un equipo que sepa diseñar la isla correcta para cada componente, decidir qué directiva de hidratación le corresponde y mantener la integración con el CMS elegido al día. No es una plantilla que se instala y funciona sola, como sí puede serlo un tema genérico de WordPress con un constructor visual de por medio.
Para una empresa sin equipo técnico interno, la opción realista es encargar el proyecto a una agencia de desarrollo de software a medida con experiencia en arquitectura de islas, y pedir antes una auditoría web si la migración parte de un sitio existente: sirve para saber cuánto tráfico depende hoy de funciones que habría que rehacer.
Astro, Next.js y WordPress clásico frente a frente
Comparar los tres solo por velocidad de carga es incompleto: lo que decide la elección es el tipo de sitio y quién lo mantiene después. La tabla resume los casos donde cada opción suele ganar, a precios orientativos de mercado en España.
| Criterio | Astro | Next.js | WordPress clásico |
|---|---|---|---|
| JavaScript por defecto | Cero, solo en las islas marcadas | El necesario para la aplicación completa | El que añada cada plugin instalado |
| Mejor caso de uso | Web de contenido, blog, catálogo sin carrito propio | Portal con login, panel de cliente, ecommerce con checkout propio | Equipo editorial sin desarrollador fijo |
| Hosting típico | Estático o edge, desde unos pocos euros al mes | Plataforma de aplicación, coste por proyecto y por uso | Hosting gestionado con soporte de plugins |
| Quién lo mantiene | Desarrollador con conocimiento de islas | Equipo de frontend y backend | Editor sin perfil técnico, con soporte puntual |
| Migrar contenido existente | Exige reescribir las plantillas como componentes | Exige reescribir las plantillas como componentes | Directo si el contenido ya está en WordPress |
Preguntas frecuentes sobre Astro
¿Astro sirve para un ecommerce?
Sirve bien para el catálogo y el contenido, pero el carrito, el checkout y la cuenta de cliente necesitan estado de aplicación que Astro no resuelve solo: ahí se suele combinar con una isla en React o Vue, o con un framework aparte para esa sección del sitio.
¿Se puede migrar un WordPress a Astro sin perder el SEO?
Sí, si se conservan las URLs y se añaden redirecciones 301 en las que cambien: el posicionamiento depende de las URLs y del contenido indexado, no del framework que los sirve. El riesgo real está en perder metadatos durante la migración.
¿Cuánto tarda una migración a Astro?
Para una web corporativa de tamaño medio, con un CMS headless ya elegido, un equipo suele necesitar entre cuatro y ocho semanas, según cuántos componentes interactivos haya que reconstruir como islas y cuánta plantilla antigua haya que rehacer desde cero.
¿Astro necesita servidor propio?
No necesariamente: las páginas estáticas se sirven desde cualquier CDN sin servidor dedicado, y solo hace falta un entorno con Node si se usan rutas de servidor para contenido que cambia en cada petición. La mayoría de webs corporativas funcionan bien en modo estático.
Fuente: Documentación oficial de Astro (Islands architecture)
