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.