En 2024, un cliente llegó con una web en Elementor que tenía un PageSpeed de 34 en mobile. Tenía 18 plugins instalados, imágenes de 3MB sin comprimir y cargaba 1.4MB de JavaScript que el navegador tenía que procesar antes de mostrar nada.

El cliente no era un técnico. Era un director de marketing que había contratado a una agencia tres años antes para “tener web rápida y moderna”. La agencia le entregó algo que se veía bien en el ordenador de su oficina con fibra de 600Mb. En el mundo real, con conexiones 4G normales, tardaba 8 segundos en cargar.

Cada día que pasaba, ese tiempo de carga estaba costando clientes.

Qué es un constructor visual y por qué se adoptó masivamente

Elementor, Divi, Beaver Builder, Webflow, Squarespace, Wix. Todos comparten la misma propuesta: diseña visualmente, sin código, y obtén una web en horas.

La propuesta es legítima. Democratizó la creación de webs para negocios que no podían permitirse un equipo técnico. Y para ciertos casos de uso —una web corporativa que se actualiza dos veces al año y cuyo tráfico es mayoritariamente desde escritorio en conexiones rápidas— funciona perfectamente bien.

El problema empieza cuando las prioridades cambian: cuando el tráfico mobile supera al de escritorio, cuando el negocio depende de que Google te encuentre, cuando la web tiene que ser rápida porque cada segundo de espera tiene un coste medible.

Qué hay debajo del capó: la diferencia técnica

Los constructores visuales generan HTML a través de capas de abstracción. Cuando diseñas una sección en Elementor, el constructor genera HTML envuelto en divs de control, carga su propio CSS con todos los estilos posibles (aunque uses el 10%), y añade JavaScript para las animaciones, el editor en vivo y las funcionalidades interactivas.

El resultado es que una página simple —título, párrafo, imagen, botón— puede generar 50+ elementos DOM anidados, 200-400KB de CSS del que usas el 5%, y 100-300KB de JavaScript que el navegador ejecuta en el hilo principal.

Astro funciona al revés. Partes de cero. Cada componente genera exactamente el HTML que defines. No hay CSS que no hayas escrito. No hay JavaScript cargándose a menos que explícitamente lo incluyas. Una página de Astro puede pesar 10KB de HTML + 5KB de CSS. La misma página en Elementor pesa 1MB+.

La diferencia en PageSpeed refleja esto directamente: un 95-100 en Astro vs un 40-70 típico en Elementor optimizado. Y esa diferencia no es estética, es un factor de posicionamiento en Google y un factor de conversión.

El modelo de islas: JavaScript solo donde hace falta

La innovación técnica principal de Astro es su modelo de “islas de componentes”. Por defecto, Astro genera HTML puro sin JavaScript. Si necesitas interactividad en algún componente concreto —un carrito, un formulario dinámico, un mapa— puedes añadir React, Vue o Svelte solo en ese componente, y el resto de la página sigue siendo HTML estático.

El resultado: el navegador no ejecuta JavaScript hasta que llega a un componente que lo necesita. Y esos componentes pueden cargarse con prioridad diferida (cuando el usuario los ve, cuando el navegador está idle, o de forma inmediata si son críticos).

Esto es lo que hace que Astro consiga 100/100 en PageSpeed incluso en páginas con interactividad. El JavaScript existe, pero solo donde lo necesitas y cargado de la forma más eficiente posible.

Cuándo un constructor visual tiene sentido

No todo proyecto necesita Astro. Hay casos en los que un constructor visual es la elección correcta:

  • Necesitas editar contenido frecuentemente sin intervención técnica. Si tu equipo de marketing actualiza la web cada semana y no tiene acceso a un desarrollador, un CMS visual como Webflow o un WordPress bien configurado tiene sentido.
  • Tienes un e-commerce con lógica compleja. WooCommerce + Elementor, a pesar de sus problemas de rendimiento, tiene un ecosistema de plugins para gestión de inventario, variantes de producto, descuentos y pasarelas de pago que Astro no resuelve out of the box.
  • El presupuesto no permite desarrollo a medida. Una web en Webflow hecha por un buen diseñador, bien optimizada, puede ser una solución funcional para una empresa que está arrancando.

Cuándo Astro (o un generador estático) es la respuesta correcta

  • Tu web es principalmente informacional. Portfolio, web de servicios, landing page de producto, blog de contenidos. Si el contenido es estático o semi-estático, no hay razón para cargar la infraestructura de un CMS dinámico.
  • El SEO es una parte crítica de tu estrategia de adquisición. La velocidad de carga es un factor de posicionamiento directo desde 2021 (Core Web Vitals). Una web lenta no puede competir con una rápida en Google.
  • Tienes un equipo técnico o acceso a uno. La barrera de Astro no es la complejidad técnica —la curva de aprendizaje es razonable— sino que requiere alguien que escriba código.
  • Quieres que la web dure. Un sitio estático bien construido no tiene dependencias que caducan, vulnerabilidades de plugins que parchear, ni base de datos que mantener. Puede vivir en producción durante años con mantenimiento mínimo.

El coste de la deuda técnica de los constructores

Hay un coste que nadie menciona al vender constructores visuales: la deuda técnica que acumulan. Cada plugin añadido es una dependencia que puede romperse con la siguiente actualización de WordPress. Cada actualización de Elementor puede cambiar el comportamiento de los estilos. Cada vez que el equipo de marketing añade una nueva sección usando el editor visual, el tamaño de la página crece un poco más.

En proyectos de 3-4 años de antigüedad, el resultado típico es una web que nadie quiere tocar porque “quién sabe qué se rompe”. Un constructor visual que era una ventaja de productividad al principio se convierte en una fuente de fricción constante.

Astro tiene deuda técnica también —todo el software la tiene— pero su naturaleza es diferente: el HTML que genera es predecible, los componentes son aislados, y no hay capas de abstracción opaca entre lo que escribes y lo que el navegador renderiza.

La pregunta que hacemos antes de recomendar

En Zatenk, antes de recomendar Astro o cualquier otra tecnología, hacemos siempre la misma pregunta: ¿quién va a mantener esto y para qué lo necesita?

No hay una respuesta universal. Hay herramientas adecuadas para cada contexto. Lo que sí es universal es que la decisión debe tomarse con los datos sobre la mesa: métricas de rendimiento actuales, objetivos de negocio, capacidades del equipo, y coste de mantenimiento a 3 años.

Una web que carga en 1.5 segundos y que convierte el doble que la anterior a 7 segundos no es un ejercicio técnico. Es una decisión de negocio.