El costo oculto de React es la hidratación: el proceso donde el navegador ejecuta JavaScript para hacer interactivo el HTML estático. En dispositivos de gama media, esto dispara el Total Blocking Time (TBT), degradando la experiencia. Volver a Vanilla JS o usar Astro permite hidratación selectiva, enviando código solo donde es estrictamente necesario.

El Sesgo del Dispositivo (The M3 Trap)#

Como ingenieros, vivimos en una burbuja de hardware. Desarrollamos interfaces complejas sobre procesadores de última generación y conexiones de fibra óptica, olvidando que el usuario promedio navega desde un dispositivo de $200 USD con una conexión 4G inestable.

Esta brecha de rendimiento está matando la conversión. Lo que para ti es un proceso de milisegundos, para un procesador ARM de gama baja es una tarea hercúlea que congela la UI. Es la clásica excusa de funciona en mi máquina , pero elevada a nivel de arquitectura.

120ms ↘
TBT (MacBook M3)
2400ms ↗ CRÍTICO
TBT (Moto G - 4x Throttle)

¿Qué es la Hidratación y por qué es cara?#

En una SPA (Single Page Application) tradicional, el servidor envía un HTML mínimo y un bundle gigante de JavaScript. El navegador debe:

  1. Descargar el JS.
  2. Parsear y compilar el código.
  3. Ejecutar la lógica para “rehidratar” los nodos del DOM y adjuntar los event listeners.

Este proceso de reconciliation es costoso porque es un “todo o nada”. Incluso si tu página es 90% contenido estático (un blog, una landing, un e-commerce), React necesita descargar y ejecutar el runtime completo para que ese único botón de “Comprar” funcione. El hilo principal (main thread) se bloquea, y el usuario intenta hacer scroll en una página que parece lista pero está muerta por dentro .

Astro y la Arquitectura de Islas: El fin del “Todo o Nada”#

Astro rompe este paradigma mediante la Arquitectura de Islas. En lugar de envolver toda la aplicación en un runtime de JS, el servidor genera HTML puro. Si necesitas interactividad, creas una “Isla” y defines cuándo debe hidratarse.

ProductPage.astro 
---
import Header from "./Header.astro"" // Estático por defecto
import ImageGallery from "./ImageGallery.tsx"" // Componente React
import BuyButton from "./BuyButton.tsx"" // Componente React
---

<Header />

<main>
  <ImageGallery client:load />

  <p>Descripción técnica del producto...</p>

  <BuyButton client:visible />
</main>

Al usar la directiva client:visible, el JS del botón de compra ni siquiera se descarga hasta que el componente entra en el viewport. Esto reduce drásticamente el JS inicial y libera el hilo principal para lo que realmente importa: la legibilidad y la respuesta inmediata. Si quieres profundizar en esto, revisa mi Guía de Astro Islands.

Benchmarks Reales: TBT y LCP en móviles de gama media#

Diccionario de Supervivencia
Hidratación (Hydration)

Proceso donde el framework de JS se ejecuta en el cliente para “revivir” el HTML estático enviado por el servidor. Es el principal culpable del TBT alto en SPAs tradicionales.

Total Blocking Time (TBT)

Métrica que mide cuánto tiempo estuvo bloqueado el hilo principal, impidiendo que el usuario interactúe con la página.

Astro Islands

Arquitectura que permite islas de interactividad aisladas en un mar de HTML estático, evitando la hidratación global innecesaria.

Los datos no mienten. Al migrar de una arquitectura SPA a Islas, el ahorro en el Main Thread es masivo. En dispositivos con CPU throttling (simulando un gama media), la diferencia entre renderizar un componente React pesado vs. una Isla de Astro puede ser la diferencia entre una sesión exitosa y un rebote.

Comparativa de TBT entre React SPA y Astro Islands en dispositivos móviles

Mientras que React mantiene ocupado al procesador intentando entender todo el árbol de componentes, Astro ya ha entregado un HTML interactivo. Es optimización por omisión.

Matriz de Decisión: ¿Cuándo quedarte en React?#

No voy a ser un extremista. React es una herramienta increíble para aplicaciones con un estado altamente denso y compartido. Si estás construyendo el nuevo Figma o un Dashboard financiero con actualizaciones en tiempo real cada 100ms, una SPA sigue siendo la opción pragmática.

Decision Matrix
  • Usa Astro/Vanilla si: Es un sitio de contenido (Blog, E-commerce, Docs, Landing). El SEO es crítico y el TBT debe ser mínimo.
  • Usa React (SPA) si: La app requiere persistencia de estado compleja entre rutas (ej: un reproductor de música que no debe cortarse) o es una herramienta de edición intensiva.

Los Trade-offs de la Pragmática#

Elegir este camino no es gratis. Al moverte a un enfoque Multi-Page (MPA) con Islas:

  1. Estado Global: Compartir estado entre dos islas de frameworks distintos (o incluso del mismo) requiere herramientas como nanostores.
  2. Ecosistema: Pierdes la capacidad de usar librerías que asumen que toda la app vive dentro de un <Provider> gigante.
  3. Mentalidad: Debes aprender a pensar en componentes aislados, no en una aplicación monolítica.

Conclusión y Próximos Pasos#

La mejor línea de código es la que no se envía al cliente. Antes de instalar npx create-react-app por inercia, pregúntate: ¿Mi usuario realmente necesita 150kb de runtime para leer un artículo? La respuesta suele ser un rotundo no. Yo mismo implementé esta filosofía en este sitio Campa.dev, logrando un score de 100 en Lighthouse sin sacrificar la UX.