Astro por dentro: cómo funciona realmente (y por qué es tan rápido)

En nuestro artículo anterior, explicamos por qué dejamos WordPress para los proyectos de nuestros clientes. Ese artículo exploró los riesgos de seguridad, los problemas de rendimiento y la carga de mantenimiento que nos llevaron a hacer un cambio. Ahora es momento de explicar a qué nos pasamos y cómo funciona a nivel técnico. Elegimos Astro como la tecnología base para todos los sitios web nuevos de clientes, y actualmente estamos migrando seis sitios WordPress existentes y varios sitios estáticos de cientos de páginas a este nuevo estándar. Astro no es solo otro framework de JavaScript. Representa un enfoque fundamentalmente diferente para construir sitios web con mucho contenido.

Cero JavaScript por defecto

La mayoría de los frameworks modernos envían una cantidad considerable de JavaScript al navegador, incluso para contenido estático. React, Next.js, Nuxt y SvelteKit, todos envían su runtime al cliente. Una simple página de "Quiénes somos" puede descargar cientos de kilobytes de código del framework: lógica de hidratación, bibliotecas de diffing del DOM virtual y gestión de estado. El navegador tiene que descargar, analizar, compilar y ejecutar todo ese JavaScript antes de que la página sea completamente interactiva.

Astro hace exactamente lo contrario. Renderiza todo como HTML estático en el momento del build y no envía JavaScript al navegador por defecto. Si tienes una página estática sin elementos interactivos, Astro genera HTML y CSS puros. El navegador recibe un markup liviano, lo muestra de inmediato y no tiene que procesar ningún JavaScript. Sin hidratación, sin DOM virtual, sin sobrecarga del framework. El resultado son cargas de página notablemente más rápidas y menor consumo de ancho de banda, especialmente en redes lentas o dispositivos menos potentes.

Islands Architecture

Esta es la innovación clave de Astro. Los frameworks tradicionales usan un enfoque de "hidratar todo": aunque solo un pequeño formulario de contacto necesite interactividad, el árbol completo de componentes de la página se vuelve a renderizar en el cliente. Todo el JavaScript asociado se descarga y ejecuta para la página entera.

Astro te permite marcar componentes interactivos específicos como "islas". Piensa en tu sitio web como un continente de HTML estático con pequeñas islas independientes de funcionalidad JavaScript. Un formulario de contacto, un widget de búsqueda, un carrusel de imágenes o una burbuja de chat pueden ser cada uno una isla. Cada isla se hidrata de forma independiente, cargando JavaScript solo para ese componente específico. El resto de la página (encabezados, navegación, contenido, pie de página) permanece como HTML sin JavaScript.

También controlas cuándo se hidratan las islas:

• client:load se hidrata inmediatamente al cargar la página, para elementos interactivos críticos.
• client:idle se hidrata después de que el navegador termina el renderizado inicial, priorizando la visualización del contenido.
• client:visible se hidrata solo cuando el componente aparece en pantalla al hacer scroll, ideal para elementos debajo del pliegue.
• client:media se hidrata cuando coincide una media query de CSS, habilitando la hidratación responsiva.

Una página con un solo formulario interactivo descarga JavaScript únicamente para ese formulario. No para la navegación, no para el pie de página, no para las secciones de contenido. Esto reduce drásticamente la carga inicial de JavaScript.

Estático y SSR: elige por página

La mayoría de los frameworks te obligan a una elección binaria: construir un sitio puramente estático o una aplicación completamente renderizada en el servidor. Astro te permite elegir tu estrategia de renderizado página por página.

Las páginas de servicios, las páginas "acerca de" y las landing pages que cambian con poca frecuencia pueden ser completamente estáticas. Se generan como HTML en el momento del deploy, se sirven instantáneamente desde un CDN y su hosting cuesta casi nada. Los artículos del blog, los casos de estudio y los listados de productos que necesitan datos frescos pueden renderizarse en el servidor, consultando una base de datos en cada solicitud.

Usamos exactamente este patrón en Med-Vision, un sitio de consultoría de salud construido con Astro 4 SSR. Las páginas principales de servicios y "acerca de" son completamente estáticas para máxima velocidad. Los artículos del blog y los casos de estudio consultan MariaDB en cada solicitud, así el contenido nuevo aparece de inmediato sin necesidad de reconstruir todo el sitio. Este enfoque híbrido te da la velocidad y seguridad de los sitios estáticos para el contenido base, combinado con las capacidades dinámicas de SSR donde las necesitas. También es la forma en que conectamos nuestro CMS headless personalizado con los sitios Astro de nuestros clientes.

Las ventajas

Nuestra decisión de estandarizarnos en Astro se basó en varias ventajas concretas:

• Agnóstico de framework: Usa React, Vue, Svelte, Preact, Solid o HTML puro dentro del mismo proyecto. Elige la herramienta adecuada para cada isla interactiva, o prescinde de los frameworks por completo para el contenido estático.
• Rendimiento excepcional desde el inicio: Cero JavaScript por defecto más Islands Architecture entrega consistentemente puntuaciones de Lighthouse de 95 a 100.
• Modelo mental simple: Escribe HTML y CSS para el contenido. Agrega interactividad solo donde sea necesario. No necesitas pensar en todo como un "componente" ni gestionar estados complejos para contenido estático.
• Diseñado para contenido: Construido para manejar markdown, MDX y contenido de CMS headless de forma eficiente.
• Ecosistema en crecimiento: Integraciones oficiales para Tailwind CSS, MDX, generación de sitemaps, optimización de imágenes (AVIF, WebP) y feeds RSS.
• Soporte nativo de TypeScript: Tipado seguro y mejores herramientas para proyectos grandes.
• Documentación excelente: Clara, completa y práctica.

Las desventajas reales

Ninguna tecnología es perfecta. Estos son los compromisos reales:

• Ecosistema más pequeño que Next.js: Menos plugins de terceros, menos tutoriales y menos respuestas en Stack Overflow para problemas específicos. La comunidad está creciendo rápido, pero todavía no está tan establecida.
• No ideal para SPA complejas: Si tu proyecto es fundamentalmente una aplicación de una sola página con enrutamiento complejo del lado del cliente y gestión de estado extensa (un dashboard SaaS, una herramienta de gestión de proyectos), usa Next.js o SvelteKit en su lugar.
• SSR requiere un servidor Node.js: El modo estático es fácil de alojar en cualquier lugar. El modo SSR necesita un proceso Node.js, lo que añade complejidad de hosting comparado con archivos puramente estáticos.
• Curva de aprendizaje para equipos acostumbrados a WordPress: Pasar de WordPress a un proceso de build basado en JavaScript requiere entender componentes, herramientas de build y gestores de paquetes. La inversión vale la pena, pero es real.
• El paso de build añade complejidad: Comparado con subir archivos HTML sin procesar, el proceso de build de Astro es una capa adicional. Es lo que habilita los beneficios de rendimiento, pero es algo a considerar para proyectos simples.

Quién debería usar Astro (y quién no)

Ideal para: Sitios de marketing, portafolios, blogs, documentación, sitios empresariales de varias páginas, landing pages y cualquier sitio web centrado en contenido donde la mayoría de las páginas son principalmente informativas con elementos interactivos ocasionales.

No tan ideal para: Aplicaciones web completas (dashboards SaaS, herramientas de gestión de proyectos), plataformas de colaboración en tiempo real o sitios donde el 90% de la interfaz es interactiva con mínimo contenido estático. Para esos casos, usa Next.js, SvelteKit o un framework dedicado a SPA.

El punto fuerte está en los sitios donde la mayoría de las páginas sirven contenido con algunos componentes interactivos. Eso describe a la gran mayoría de los sitios web empresariales, y es exactamente por eso que adoptamos Astro como nuestro estándar.

Astro vs. Next.js vs. WordPress