El problema de la hidratación completa

La hidratación es el proceso mediante el cual React toma el HTML renderizado en el servidor y le añade detectores de eventos de JavaScript. El servidor envía el HTML inicial (rápidamente); después, el navegador descarga el paquete de JavaScript y React «hidrata» el HTML estático para hacerlo interactivo. Hasta que termina la hidratación, la página parece interactiva, pero no lo es.

Una aplicación de página única tradicional envía todo el paquete de JavaScript al navegador. React debe descargarlo, analizarlo, ejecutarlo y después añadir detectores de eventos a cada componente del árbol. En aplicaciones grandes, este proceso puede tardar varios segundos en dispositivos móviles de gama media.

El tiempo hasta la interactividad mide cuánto tiempo pasa antes de que el usuario pueda interactuar con la página. La hidratación bloquea directamente el TTI: la página puede parecer lista (el HTML renderizado en el servidor es visible), pero los botones y formularios no responden hasta que React termina de añadir los detectores de eventos. Un TTI alto ofrece una mala experiencia de usuario.

Considere una página de marketing: el 80 % del contenido consiste en texto estático, imágenes y encabezados que nunca cambian. Solo el 20 % incluye widgets interactivos, como un formulario para suscribirse a un boletín o un reproductor de vídeo. La hidratación de una SPA tradicional sigue ejecutándose en el 100 % de la página y procesa componentes estáticos innecesariamente.

El análisis de rendimiento de Chrome DevTools revela el coste de la hidratación. En el gráfico de cascada del hilo principal, puede identificar la tarea «React hydration» como un bloque largo de ejecución de JavaScript después del pintado inicial. Cuanto más largo sea este bloque, más ocupado estará el hilo principal y menos receptiva será la página.

Cuanto más grande sea el árbol de componentes de React, más trabajo requerirá la hidratación. React debe visitar cada componente, comparar el HTML renderizado en el servidor con lo que renderizaría el componente y añadir detectores de eventos. Una página compleja con cientos de componentes puede tener una sobrecarga de hidratación apreciable incluso en dispositivos rápidos.

React 18 introdujo la hidratación concurrente, que permite dividir la hidratación en fragmentos más pequeños y ceder el control al navegador entre ellos. Esto evita que el navegador parezca completamente bloqueado durante la hidratación de árboles grandes. Sin embargo, la hidratación concurrente reduce el impacto, pero no elimina el coste fundamental.

La hidratación selectiva (mediante Suspense) permite que React hidrate los componentes según su prioridad; las interacciones del usuario activan la hidratación inmediata del componente correspondiente. Esto mejora la capacidad de respuesta, pero sigue funcionando dentro de un único árbol de React: todos los componentes del árbol terminan hidratándose.

La idea fundamental en la que se basa la arquitectura de islas es que la mayor parte de una página típica no necesita JavaScript en absoluto. Las barras de navegación, las secciones principales, los enlaces del pie de página, el texto de las entradas de blog y las descripciones de productos son elementos puramente presentacionales. Forzar su hidratación es innecesario por definición.

Los estudios de equipos de rendimiento web muestran que el análisis y la ejecución de JavaScript son el coste dominante en los dispositivos móviles. Un paquete de JavaScript de 300 kB tarda entre 2 y 3 segundos en analizarse en un teléfono Android representativo. Reducir el JavaScript enviado al navegador ofrece beneficios de rendimiento mucho mayores que cualquier optimización interna de React.

Cada kilobyte de JavaScript que se añade a una aplicación de React aumenta el trabajo de hidratación. Aunque un componente sea puramente decorativo, si forma parte del árbol de React participa en la hidratación. Este «coste de la hidratación» crece con el tamaño de la aplicación y hace que resulte cada vez más difícil mantener buenos valores de TTI a medida que las aplicaciones crecen.

¿Cuál es la relación entre la hidratación de React y el tiempo hasta la interactividad (TTI)?

La hidratación tradicional de React procesa todo el árbol de componentes, incluso el contenido estático que no necesita JavaScript. Esto bloquea el tiempo hasta la interactividad y no escala bien con el tamaño de la aplicación. Las mejoras de hidratación concurrente y selectiva de React 18 reducen el impacto, pero no eliminan el coste fundamental. La idea principal es que la mayor parte del contenido de una página no necesita JavaScript, por lo que la hidratación completa resulta innecesaria.