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 hoy, la métrica técnica que más impacta en la facturación es el 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 SPA (Single Page Application) tradicional como Next.js, ocurre un proceso llamado Hidratación:
- El servidor envía HTML (bien).
- El navegador descarga un gran paquete de JS (lento).
- 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: Amazon calculó que cada 100ms de latencia les costaba un 1% en ventas. La hidratación suele costar entre 500ms y 2000ms en redes 4G. Haz los números.
La solución: Islas de Interactividad (Astro)
Astro propone un cambio de paradigma: HTML First.
Por defecto, este sitio no envía ni un solo byte de JavaScript al cliente. Es solo HTML y CSS. Esto garantiza:
- Time to Interactive (TTI): 0ms.
- Google PageSpeed: 100/100 casi garantizado.
- SEO: Indexabilidad perfecta.
¿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): Todo el layout, el sidebar y el contenido pasan por el proceso de hidratación de React, aunque sean estáticos. El usuario descarga el código de la librería de React (~40KB) solo para leer texto.
En Astro:
---// Layout y contenido: 0KB JS enviados al navegadorimport Header from './Header.astro';import Footer from './Footer.astro';import InteractiveCounter from './InteractiveCounter.jsx';---
<html> <body> <Header /> <main> <h1>Hola Mundo</h1>
<InteractiveCounter client:visible /> </main>
<Footer /> </body></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, Google nos premia con mejores rankings y los usuarios con mayor retención.
Resumen
No elijas tu stack tecnológico por lo que está de moda. Elígelo por la eficiencia. Si tu contenido es mayormente estático (blogs, landings, documentaciones), Astro ofrece una ventaja competitiva injusta frente a sus competidores hechos en React.