Hidratación: Definición, Proceso, Tradeoffs Performance
Hidratación es el proceso donde JS cliente se attacha al HTML server-rendered, hace markup estático interactivo. Caro; hurts INP.
¿Qué es hidratación?
Hidratación es el proceso donde JavaScript en el cliente se "attacha" al HTML server-rendered, convirtiendo markup estático en una aplicación interactiva. Después de que SSR envía HTML al navegador, el bundle JS descarga, parsea y re-corre el component tree para attachar event handlers, restaurar state y hacer la página interactiva.
La hidratación es fundamental para frameworks basados en SSR. También es el costo primario de SSR, hidratación pesada es la causa principal de mal INP.
La secuencia hidratación
- Servidor renderea HTML y envía al navegador
- Navegador muestra HTML
- Navegador descarga bundle JS
- JS parsea + ejecuta
- JS recorre DOM existente, matchea elements a components
- JS attacha event handlers, inicializa state
- Página ahora realmente interactiva
Por qué hidratación es lenta
- Component tree entero re-corre.
- Tamaño bundle JS.
- Síncrono en main thread.
- Competencia recursos.
- Cold starts en devices lentos.
Soluciones modernas al costo hidratación
| Técnica | Cómo funciona | Usado por |
|---|---|---|
| Hidratación parcial | Solo hidratar components marcados interactivos | Astro Islands |
| Streaming SSR | Servidor stream chunks HTML | React 18+, Next.js |
| Hidratación progresiva | Hidratar al entrar viewport | RSC, Astro |
| Resumability (Qwik) | Skip hidratación; lazy-load handlers | Qwik |
| React Server Components | Components corren solo server-side | Next.js App Router |
| Hidratación selectiva | Hidratar parte usuario interactúa primero | React 18+ |
Hidratación vs no-hidratación approaches
| Approach | Costo JS | Interactividad |
|---|---|---|
| SPA (CSR) | Todo JS upfront | Interactivo después load JS |
| SSR + hidratación | JS completo en cada página | Visible rápido, interactivo después hidratación |
| SSG (no JS) | Cero JS | Estático |
| Hidratación parcial | Solo components interactivos | Mostly estático, islands interactivos |
| Resumability | ~No JS upfront | Visible + clickeable inmediatamente |
Problemas hidratación comunes
Mismatch hidratación
HTML server-rendered difiere del output client-rendered.
Hidratación lenta en páginas pesadas
Páginas con miles de components hidratan lento.
Hidratación bloqueando input usuario
Usuario clickea botón mientras hidratación corre.
Mejores prácticas hidratación
- Minimizar JS shipped.
- Usar hidratación parcial.
- Evitar mismatches SSR/CSR.
- Stream HTML.
- Defer hidratación non-crítica.
- Testear en devices reales.
- Considerar zero-JS para páginas contenido.
- Monitor INP en producción.
Pitfalls hidratación comunes
- Mismatches hidratación en dev.
- Referencias window durante render.
- IDs random.
- Init pesado state global.
- Big component trees en cada route.
- Scripts third-party síncronos.
- Olvidar testear en devices lentos.
FAQ: Hidratación
¿Por qué se necesita hidratación?
SSR envía HTML estático para primer paint rápido. Hidratación añade la capa JS.
¿Cuánto debería tomar la hidratación?
< 100ms en device rápido, < 300ms en mobile mid-tier.
¿Diferencia entre hidratación y rendering?
Rendering: producir HTML. Hidratación: attachar JS al HTML existente.
¿Qué es "React hydration"?
ReactDOM.hydrateRoot() recorre DOM server-rendered.
¿Puedo evitar hidratación enteramente?
Para páginas sin interactividad: sí. Para interactivas: vía Qwik o partial hydration.
¿Qué es React Server Components?
Components que corren solo en servidor.
¿Afecta hidratación al SEO?
Indirectamente, vía Core Web Vitals (INP, LCP).
Testea costo hidratación con LoadFocus
LoadFocus corre auditorías Lighthouse desde 25+ regiones, midiendo INP y Total Blocking Time. Regístrate en loadfocus.com/signup.
Herramientas LoadFocus relacionadas
Lleva este concepto a la práctica con LoadFocus, la misma plataforma que potencia todo lo que acabas de leer.