Hidratación (hydration): definición, proceso y coste

La hidratación conecta JavaScript con HTML renderizado en el servidor para hacerlo interactivo. Cómo funciona, su efecto en INP y cómo reducir su coste.

¿Qué es la hidratación?

La hidratación (hydration) es el paso en el que el JavaScript del navegador se engancha al HTML que el servidor ya ha renderizado. El framework reutiliza el DOM existente, conecta los controladores de eventos y reconstruye el estado de los componentes, de modo que una página de aspecto estático pasa a ser interactiva. Es la segunda mitad del renderizado en el servidor (SSR) en frameworks como React con Next.js. Su coste es un motivo habitual por el que una página que parece rápida responde con lentitud a toques y clics.

Cómo funciona la hidratación

  1. El servidor renderiza la página a HTML y la envía, de modo que el navegador puede pintar contenido pronto.
  2. El navegador descarga, analiza y ejecuta el paquete de JavaScript.
  3. El framework vuelve a ejecutar los componentes en el navegador y los asocia con los nodos DOM existentes. En React es hydrateRoot.
  4. Se enlazan los controladores de eventos y el estado. A partir de aquí la página es interactiva.

Entre los pasos 1 y 4 la página parece lista, pero los clics pueden ignorarse o retrasarse. Ese intervalo es el coste de la hidratación y se refleja en la Interaction to Next Paint (INP). Google evalúa INP en el percentil 75 de cargas reales: 200 ms o menos es bueno, más de 500 ms es malo (web.dev).

Ejemplo

Una página de producto se renderiza en el servidor y aparece en menos de un segundo. El paquete del framework es grande y a la vez carga un widget de chat. Un visitante con un móvil de gama media toca "Añadir al carrito" mientras la hidratación sigue ejecutándose en el hilo principal. El toque queda en cola y el botón reacciona uno o dos segundos después. El HTML del servidor fue rápido; la hidratación que había detrás no.

Por qué la hidratación es lenta

  • Vuelve a ejecutar el árbol de componentes en el navegador, incluso en las partes que nunca cambian.
  • El paquete debe descargarse y analizarse primero, así que más JavaScript implica un intervalo mayor.
  • Se ejecuta en el hilo principal, que también atiende la entrada del usuario.
  • Compite con imágenes, scripts de terceros y anuncios.
  • Depende del dispositivo. Un móvil puede ser varias veces más lento que un portátil de desarrollo.

Técnicas para reducir el coste de la hidratación

  • Enviar menos JavaScript. La división de código y eliminar código sin usar acortan cada paso.
  • Islas. Astro renderiza las páginas a HTML plano y añade JavaScript solo a los componentes con una directiva client:*; cada isla se hidrata por separado, por ejemplo al cargar, en reposo o al hacerse visible (documentación de Astro).
  • Streaming y Suspense. renderToPipeableStream de React envía primero la estructura y transmite el resto según llegan los datos, de modo que el contenido aparece antes de cargar los scripts (documentación de React).
  • Server Components. Los componentes que se ejecutan solo en el servidor no necesitan JavaScript propio en el cliente.
  • Reanudabilidad (resumability). Qwik pausa la ejecución en el servidor y la reanuda en el navegador en lugar de reproducir la lógica de la aplicación (documentación de Qwik).
  • Sin hidratación. Las páginas puramente estáticas de la generación de sitios estáticos no la necesitan, y la carga diferida del código fuera de pantalla mantiene ligera la primera carga.

Errores frecuentes de hidratación

  • Desajustes de hidratación (mismatch). El renderizado del cliente debe producir la misma salida que el del servidor. Causas típicas: marcas de tiempo y formato según la configuración regional, APIs solo del navegador como window.matchMedia durante el renderizado y comprobaciones typeof window en la lógica de render. React los trata como errores: puede recuperarse, pero eso puede ralentizar la aplicación o asociar controladores a elementos equivocados (documentación de React).
  • Corregir desajustes con un segundo renderizado. Cambiar el contenido en useEffect funciona, pero los componentes se renderizan dos veces y la interfaz puede cambiar a la vista tras la carga. suppressHydrationWarning es solo para elementos concretos.
  • Hidratarlo todo. Las partes de solo contenido, como pies de página y texto de artículos, rara vez necesitan JavaScript.
  • Preparar estados pesados al arrancar y cargar scripts de terceros de forma síncrona retrasan la interactividad.
  • Probar solo en un portátil rápido. Los problemas de hidratación aparecen en móviles reales de gama media.

Medir la hidratación con monitorización

La hidratación no se ve en una captura, así que hay que medirla. El verificador gratuito de Core Web Vitals muestra LCP, INP y CLS de usuarios reales a partir de datos del Chrome UX Report, agregados durante 28 días. Para datos de laboratorio, la monitorización de velocidad de página ejecuta auditorías Lighthouse desde 25 regiones en la nube, registra el Total Blocking Time (una métrica de laboratorio que refleja trabajo del hilo principal como la hidratación) y puede avisarle cuando una métrica empeora. Vea también cómo monitorizar Core Web Vitals con alertas e informes y dominar JavaScript para el rendimiento (ambos artículos en inglés).

Preguntas frecuentes: hidratación

¿Por qué hace falta la hidratación?

El HTML renderizado en el servidor es solo marcado. La hidratación añade el JavaScript que lo hace interactivo, con controladores de eventos, estado y efectos, sin descartar el HTML que el usuario ya ve.

¿Qué diferencia hay entre renderizado e hidratación?

El renderizado produce el HTML. La hidratación enlaza JavaScript a un HTML que ya existe. En SSR primero renderiza el servidor y después llega la hidratación en el navegador.

¿Qué es un desajuste de hidratación?

Ocurre cuando el HTML del servidor difiere de lo que el cliente renderiza por primera vez, por ejemplo por una marca de tiempo o un valor propio del navegador. React muestra una advertencia y puede tener que repetir trabajo en el cliente.

¿Afecta la hidratación al SEO?

De forma indirecta. Los buscadores pueden leer el HTML del servidor, pero una hidratación lenta empeora la capacidad de respuesta y, con ella, INP, que forma parte de Core Web Vitals.

¿Se puede evitar la hidratación por completo?

Sí en páginas sin interacción, como páginas de contenido estáticas. En páginas interactivas se puede limitar con islas, Server Components o un framework reanudable como Qwik.

¿Cómo sé si la hidratación perjudica a mi sitio?

Revise INP en datos de campo y el Total Blocking Time en una ejecución de Lighthouse, y perfile después el hilo principal en un móvil de gama media para ver las tareas largas justo tras la carga.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.