Por qué usamos Astro (y cuándo no)

Después de publicar el post sobre por qué dejamos Elementor, llegaron mensajes preguntando lo mismo de formas distintas. ¿Y entonces con qué trabajáis ahora? ¿Cómo se llama eso? ¿Es para cualquier tipo de web o solo para proyectos grandes?

Este post responde esas preguntas.

La respuesta corta: Astro. Para webs corporativas, portfolios, blogs, landings y cualquier sitio donde el contenido manda y la interactividad es secundaria. No para plataformas con lógica compleja, no para tiendas online con catálogos extensos, no para aplicaciones con áreas privadas y gestión de usuarios — para esos casos existe Next.js. Pero eso ya es la respuesta larga.

Qué es Astro

Astro es un framework de desarrollo web. Eso suena técnico y no dice mucho, así que lo concreto: es la herramienta con la que escribimos el código que produce las páginas de un sitio web.

Lo que diferencia a Astro de la mayoría de herramientas similares es una sola decisión de diseño: por defecto, no envía JavaScript al navegador del usuario.

Una web hecha con React o Vue carga primero un archivo de JavaScript que se ejecuta en el navegador y genera el HTML de la página ahí mismo, en el dispositivo del usuario. Es rápido de desarrollar, pero tiene un coste: el usuario espera a que ese JavaScript se descargue, se ejecute y produzca el contenido visible. En un ordenador con buena conexión casi no se nota. En un móvil con cobertura normal, sí.

Astro hace lo contrario. Genera el HTML en el momento del build, antes de que ningún usuario llegue. Lo que llega al navegador es HTML ya construido. No hay espera para generar el contenido porque el contenido existe antes de que se pida.

El problema real con las webs lentas

Las webs lentas no suelen tener un problema de servidor o de hosting. El problema, en la mayoría de los casos, es el JavaScript.

Los frameworks modernos de frontend fueron diseñados para aplicaciones interactivas: dashboards complejos, herramientas con mucho estado, apps donde el usuario hace cosas constantemente. Para eso son excelentes. El problema es que el sector los adoptó también para webs que no necesitan nada de eso: páginas de empresa, blogs, portfolios, landings. Páginas donde el contenido es estático, donde no hay estado que gestionar, donde el usuario llega, lee y sale.

Para una web de ese tipo, cargar un framework completo es exceso de herramienta. El resultado son auditorías de PageSpeed con 55 o 60 sobre 100 en móvil, no porque el diseño esté mal, sino porque hay decenas de kilobytes de JavaScript que el navegador tiene que procesar antes de mostrar el primer texto. Plugins encima de plugins. CSS que carga aunque no se use. Fuentes que bloquean el render.

Cuando llegan proyectos a Reveled con ese perfil, la conversación siempre va al mismo sitio: el problema no es cosmético y no se arregla con un plugin de caché más. El problema es la arquitectura. Un plugin de optimización encima de una arquitectura lenta es lo mismo que poner un motor más potente en un coche con las ruedas pinchadas.

Astro parte de otra premisa: si una página no necesita interactividad, no necesita JavaScript. Y si necesita algo dinámico — un formulario, un menú animado, un elemento que responde a clics — ese componente específico recibe exactamente el JavaScript que necesita, y no más. El resto de la página sigue siendo HTML estático.

La arquitectura de islas: lo que significa en la práctica

El modelo de Astro se llama arquitectura de islas. La idea es sencilla: la página es estática por defecto, y los componentes que necesitan comportamiento dinámico son islas dentro de ese océano de HTML.

En la práctica: el header, el footer, los textos, las imágenes, la estructura completa de la página — todo eso es HTML que existe antes de que el usuario llegue. No se genera en su navegador. No espera a ningún script. El menú de navegación que se abre en móvil, el formulario de contacto con validación en tiempo real, un carrusel de proyectos — eso sí recibe JavaScript, exactamente el que necesita para funcionar.

El resultado en una auditoría de rendimiento es diferente porque el punto de partida es diferente. No hay que desactivar cosas para llegar a una buena puntuación. Hay que hacer un esfuerzo activo para bajar de 95 en Google PageSpeed Insights.

La web de Reveled que estás leyendo ahora mismo está construida en Astro. Carga en menos de un segundo en móvil, no porque hayamos hecho magia de optimización ni instalado plugins de caché encima de otros plugins, sino porque el HTML ya existe cuando llega la petición.

Lo que cambia para el cliente

El rendimiento es lo primero que se ve, pero no es lo único que cambia.

Una web en Astro son archivos de código que no dependen de ninguna plataforma propietaria, ninguna licencia de constructor visual, ningún plugin de pago que si dejas de renovar deja de funcionar. El código es del cliente, portátil, y cualquier desarrollador que entienda HTML puede leerlo y trabajar sobre él.

El hosting tampoco complica. Una web estática se sirve desde prácticamente cualquier proveedor que pueda servir archivos — sin PHP, sin base de datos, sin configuraciones especiales. Los archivos del build van al servidor y ya. Si el tráfico crece, cambias de plan.

La seguridad es otro punto que nadie suele mencionar. No hay base de datos que atacar, no hay panel de administración expuesto, no hay plugins con vulnerabilidades conocidas. El vector de ataque más común en WordPress desaparece por completo porque la arquitectura no existe. Las páginas son archivos estáticos.

Y todo el proyecto vive en Git. Cada cambio queda registrado con quién lo hizo y cuándo. Deshacer algo que rompió el diseño es un comando. Desplegar a producción es un push a la rama principal. Sin abrir paneles, sin vaciar cachés, sin cruzar los dedos.

El rendimiento en números

Core Web Vitals es la métrica que Google usa para evaluar la experiencia de usuario y que influye directamente en el posicionamiento orgánico. Tiene tres componentes: LCP (cuánto tarda en aparecer el contenido principal), INP (cuánto tarda la página en responder a interacciones) y CLS (cuánto salta el diseño mientras carga).

Una web en Astro sin errores básicos de implementación llega habitualmente a:

• LCP por debajo de 1.2 segundos, cuando el umbral para considerarse “bueno” está en 2.5
• INP prácticamente inmediato, porque hay muy poco JavaScript ejecutándose
• CLS de 0, si las imágenes tienen dimensiones declaradas y las fuentes están gestionadas correctamente

Una web en WordPress con constructor visual y diez plugins activos llega típicamente a un LCP de entre 3 y 6 segundos en móvil. Eso es territorio donde Google empieza a mostrar el sitio menos en resultados, y donde el usuario que llega desde una búsqueda tiene muchas probabilidades de volver atrás antes de leer nada.

La diferencia no es cosmética. Es estructural. Una web en Astro no rinde bien porque se ha optimizado mucho — rinde bien porque el punto de partida es otro.

Cuándo Astro no es la respuesta correcta

Dicho esto: Astro no es para todo.

Si el proyecto necesita autenticación de usuarios — área privada, perfiles, sesiones, roles — Astro puede manejarlo pero con una complejidad que no vale la pena cuando hay herramientas diseñadas específicamente para ese caso. Next.js, con su modelo híbrido de rendering y su ecosistema de librerías de autenticación, es la respuesta más sensata.

Si el cliente necesita gestionar contenido con autonomía total — publicar posts, actualizar servicios, editar textos sin tocar código ni depender de nosotros — la solución depende del volumen y la frecuencia. Para contenido que cambia poco, Markdown en el repositorio funciona bien. Para un cliente que publica cada semana, hay que añadir un CMS. En ese caso usamos Keystatic para proyectos más simples, y Payload CMS cuando el cliente necesita algo más potente o hay lógica de contenido más compleja.

Si el presupuesto es ajustado y el cliente quiere gestionar todo desde un panel familiar, WordPress sigue siendo la respuesta honesta. El rendimiento de partida es diferente y el coste de mantenimiento a lo largo del tiempo también, pero para muchos proyectos ese trade-off es perfectamente aceptable. No hay herramienta correcta en abstracto. Hay herramienta correcta para cada contexto.

Los proyectos de Reveled en Astro

La web de Reveled está construida en Astro. Cada vez que añadimos un post al blog, actualizamos un proyecto del portafolio o cambiamos un texto de servicio, el proceso es: editar el archivo Markdown, commit, push, y en dos minutos el sitio está actualizado en producción a través de GitHub Actions.

No hay panel que abrir. No hay plugin de caché que vaciar. No hay riesgo de que una actualización rompa el diseño el viernes por la tarde. El flujo de trabajo es el mismo que cualquier proyecto de código, porque es eso.

Para los proyectos de clientes que encajan con este perfil — webs corporativas, portfolios, landings de servicio, blogs — el resultado es consistente: carga rápida por defecto, proyecto en Git con historial completo, coste de mantenimiento predecible. Puedes ver cómo queda en el portafolio de Reveled.

No usamos Astro porque nos gusta. Lo usamos cuando es la respuesta que mejor encaja con lo que el proyecto necesita. La diferencia entre las dos razones, a largo plazo, se nota.

---

Si estás evaluando hacer una web nueva o llevas tiempo con una que no rinde como debería, podemos contarte qué stack tiene más sentido para tu caso concreto. Eso es exactamente lo que miramos en una consultoría. Escríbenos cuando quieras.