Zero-JS Architecture: Cuando la mejor línea de código es la que no se envía

Durante la última década, la industria del desarrollo web sufrió una alucinación colectiva: nos convencimos de que para mostrar un texto y una imagen, necesitábamos enviar 200KB de JavaScript al navegador.

Adoptamos React (y luego Next.js) para todo. El resultado es una web obesa, lenta en móviles de gama media y costosa de renderizar.

Como Business Engineer, analizo la tecnología por su retorno (ROI). Y en un sitio de contenido, la métrica técnica que más se relaciona con perder usuarios es cuánto tiempo la página parece lista sin responder: lo que Google mide en terreno como INP (Interaction to Next Paint) y en laboratorio como TBT (Total Blocking Time).

Aquí explico por qué este sitio está construido sobre Astro, apostando por una arquitectura “Zero-JS by default”.

El costo oculto de la “hidratación”

En un framework basado en React con renderizado en servidor, como Next.js, ocurre un proceso llamado Hidratación:

1. El servidor envía HTML (bien).
2. El navegador descarga un gran paquete de JS (lento).
3. El navegador ejecuta ese JS para “reactivar” el HTML y tomar el control (muy costoso en CPU).

Durante el paso 3, tu sitio parece listo, pero no funciona. Si el usuario toca un botón, no pasa nada. El hilo principal está bloqueado. Esto genera frustración y rebote.

Business fact: el dato que todo el mundo cita es que Amazon calculó que cada 100ms de latencia les costaba un 1% en ventas. Conviene citarlo con su letra chica: viene de experimentos internos de 2006 que Greg Linden contó en una charla, en otra escala y en otra web. Úsalo como dirección, no como tasa de conversión para tu sitio. La dirección sí está bien documentada: más espera, menos conversión.

La solución: Islas de Interactividad (Astro)

Astro propone un cambio de paradigma: HTML First.

Por defecto, Astro no envía ni un solo byte de JavaScript al cliente: solo HTML y CSS. Cada byte de JS que llega es una decisión explícita. Este sitio, por ejemplo, envía el buscador, el menú móvil, la navegación entre páginas, los gráficos interactivos y la analítica; el texto de los artículos, nada. Eso significa:

• Sin espera por hidratación: el contenido es usable apenas se pinta.
• Google PageSpeed: puntajes altos muy alcanzables, siempre que imágenes y fuentes estén bajo control.
• SEO: el contenido llega completo en el HTML, sin depender de que el buscador ejecute JavaScript.

¿Y si necesito interactividad? Si necesito un carrusel de imágenes o una barra de búsqueda, Astro utiliza la Arquitectura de Islas. Solo ese pequeño componente “despierta” (se hidrata), mientras que el resto de la página (el header, el footer, el artículo) permanece como HTML estático inerte.

Comparativa de código

Imagina un blog simple.

En Next.js (App Router): Los Server Components ya no se hidratan, y eso es un avance real. Pero la página igual descarga el runtime de React (del orden de 40 a 50 KB comprimido) más el payload de los componentes, y cualquier componente cliente arrastra su árbol. Para una página que es texto, sigue siendo JavaScript que no hacía falta.

En Astro:

1
---
2
// Layout y contenido: 0KB JS enviados al navegador
3
import Header from './Header.astro';
4
import Footer from './Footer.astro';
5
import InteractiveCounter from './InteractiveCounter.jsx';
6
---
7

8
<html>
9
  <body>
10
    <Header />
11
    <main>
12
      <h1>Hola Mundo</h1>
13
      <InteractiveCounter client:visible />
14
    </main>
15
    <Footer />
16
  </body>
17
</html>

La directiva client:visible es una obra maestra de ingeniería de negocio. Le dice al navegador: “No descargues ni ejecutes el código de este contador hasta que el usuario realmente haga scroll y lo vea”.

Impacto en infraestructura (coste $0)

El HTML estático es increíblemente barato de alojar.

• No requiere servidores Node.js corriendo 24/7.
• Se puede cachear agresivamente en la CDN (Edge Network).

Este sitio, al usar Astro + Vercel Edge, tiene un coste de mantenimiento virtualmente nulo. Si tuviera que renderizar cada visita con SSR (Server Side Rendering) complejo en React, necesitaría pagar por tiempo de cómputo (CPU) en cada petición.

Conclusión: La elegancia de la sustracción

En ingeniería, la solución más robusta es la que tiene menos partes móviles.

Eliminar JavaScript no es un movimiento nostálgico; es una estrategia de eficiencia. Al reducir la carga cognitiva del navegador del usuario, respetamos su batería, su plan de datos y su tiempo.

Y a cambio, los usuarios nos premian con más retención. Google también cuenta la experiencia de página como señal de ranking, aunque pesa poco frente a la relevancia del contenido: la razón de fondo para hacerlo es el usuario, no el algoritmo.