Patrones de Hidratación y Renderizado en el Mundo Real en Aplicaciones Modernas de React

Hola a todos, soy Ranjit Dandigam, actualmente trabajo como ingeniero de software en Naban. Hoy voy a hablar sobre patrones de hidratación y renderizado en el mundo real en aplicaciones modernas de React. Así que esta no es una charla genérica sobre el rendimiento de React. El enfoque es muy específico. Qué sucede entre el renderizado del HTML en el servidor y la hidratación del cliente de la interfaz de usuario transmitida y las primeras interacciones en las que los usuarios realmente pueden confiar. Así que aquí está el modelo mental principal para la charla. Una página de React no se vuelve lista en un solo paso. Primero, el servidor renderiza el HTML, luego el navegador recibe el contenedor HTML y pinta los primeros píxeles. Después de eso, se carga JavaScript. Luego, React hidrata los componentes del cliente y adjunta eventos. Algunas partes pueden transmitirse más tarde. Solo después de que todas las piezas importantes estén listas, el usuario puede confiar en la interacción. Así que cuando decimos que una página es rápida, necesitamos preguntar ¿rápida en qué etapa? Entonces, ¿fue más rápido renderizar, rápido para pintar, rápido para hidratar o rápido para que el usuario realmente haga clic y obtenga una respuesta? Esa es la diferencia que quiero dejar clara hoy.

Así que aquí está el problema común de producción. La página se ve bien. El contenido principal es visible. LCP puede parecer saludable. No hay error de JavaScript. Pero cuando el usuario hace clic en el botón de guardar, no hay retroalimentación inmediata. Así que aquí es donde los usuarios sienten que la página es lenta. Incluso si nuestra matriz de carga de página parece estar bien, la línea importante aquí es que pintado no significa listo. Esto no siempre es un error de componente. Muchas veces es un problema de sincronización entre el navegador, la carga de JavaScript, la hidratación y la primera interacción real. Así que hace unos años, la mayoría de los equipos estaban haciendo preguntas de adopción. ¿Podemos usar componentes del servidor? ¿Está listo el streaming? Pero ahora la pregunta es diferente. Así que los equipos ya están usando estos patrones. Pero ahora preguntan por qué este stream está retrasado. ¿Por qué falló la hidratación? ¿Por qué la página parece lista pero aún se siente lenta? Así que la parte difícil en 2026 no es solo aprender las APIs, la parte difícil es operar este modelo de renderizado de manera confiable en aplicaciones reales.

Así que aquí expandimos la misma idea. Así que una ruta se mueve a través de las fases.

La solicitud comienza, el servidor renderiza la UI, la estructura HTML llega al navegador, el navegador pinta. Luego se carga JavaScript, la hidratación adjunta los eventos. Después de eso, los streams se resuelven, finalmente el usuario puede confiar en la interacción. Así que el intervalo de riesgo está entre el pintado del navegador y la hidratación. Durante este intervalo, la UI puede parecer lista, pero los eventos pueden no estar adjuntos aún. Es entonces cuando los usuarios pueden hacer clic en un botón y sentir que no pasó nada. Al depurar, no solo debemos preguntar, ¿se renderizó la página? Debemos preguntar, ¿qué fase está retrasada? Aquí están los cuatro estados que realmente explican. En este caso, renderizado significa que React produjo la UI, pero eso no siempre significa que el usuario puede verla. Mientras que transmitido significa que el contenido llega más tarde, pero eso no siempre significa que está hidratado. E hidratado significa que React se adjuntó al comportamiento, pero puede no sentirse rápido si el hilo principal está ocupado. Y mientras que interactivo significa que el usuario puede hacer clic, escribir y obtener una respuesta rápidamente, pero los usuarios juzgan el estado interactivo. Nuestra arquitectura debería hacer estos estados claros en lugar de mezclarlos.

Aquí está el primer patrón, que son los límites de servidor primero. El valor predeterminado debería ser componentes del servidor. Luego añadimos uso del cliente solo donde el navegador es realmente necesario. En esta diapositiva, puedes ver los casos, estado, efectos, APIs del navegador y bibliotecas solo para cliente. El objetivo no es eliminar la interactividad. El objetivo es mantener los límites interactivos pequeños. Así que la mayor parte de la página puede renderizarse en el servidor. Solo pequeñas piezas como un botón con un estado o comportamiento del navegador necesitan hidratarse en el cliente. Como puedes ver en la imagen del lado izquierdo, la mayor parte de esto es servidor en la caja, pero mientras que solo el botón de guardar es la isla del cliente. Aquí está el patrón que nos gustaría evitar, que es el componente comienza el uso del cliente. Así que todo el componente está en el lado del cliente, luego las características de datos ocurren dentro del lado del usuario. Eso significa que el navegador debe primero cargar JavaScript, React debe ejecutarse, y solo entonces comienza la solicitud de datos. Hasta que los datos regresen, el usuario ve un esqueleto. El problema clave no es el código exacto. El problema clave es la secuencia, renderizado del cliente primero, datos obtenidos después. Donde podemos ver, tenemos un uso del cliente y luego tenemos este use effect en el cual tenemos esta llamada a la API fetch. Así que la obtención de datos está ligada a la ejecución del cliente que crea una cascada. Este es el mejor modelo donde tenemos el encabezado del viaje, resumen del viaje, y recomendaciones de hotel pueden ser renderizados por el servidor, y no necesitan un estado del navegador en este ejemplo.

Solo el botón de guardar viaje necesita un comportamiento del cliente porque tiene un manejador de clics y un estado local. Así que mantenemos la misma experiencia de usuario, pero con una superficie de hidratación más pequeña, misma interactividad, menos trabajo del cliente y depuración más fácil. Así que si miras primero la lista de renderizado del servidor, entonces podemos mirar el botón de guardar viaje en la pantalla del lado izquierdo, pantalla de ejemplo. Así que aquí está la página, que la página del servidor posee los datos en el lado del servidor. Así que aquí, si miras el viaje, que realmente espera el próximo viaje, eso significa que el servidor puede obtener los datos del viaje y producir HTML útil antes de que el navegador tome el control. También nota que el botón de guardar viaje sigue ahí.

No estamos eliminando el comportamiento del cliente. Lo estamos aislando a la parte que realmente lo necesita. Así que si ves, tenemos este await async, la llamada de sincronización, que es obtener el próximo viaje. Y luego tenemos este botón de guardar viaje con el ID del viaje. Así que el servidor posee los datos, el cliente solo posee la interacción. Así que esta es una pequeña isla del cliente, tiene un uso del cliente, tiene un uso de estado y tiene un manejador de clics.

Así que este componente pertenece al cliente, pero esta es solo una pequeña parte de la página. El resto del tablero no necesita ocultarse solo porque un botón es interactivo. Este es el límite que queremos pequeño, claro y fácil de razonar. Así que esta diapositiva trata sobre una visualización de límites.

Así que un límite de cliente-servidor no es solo una anotación de archivo, es una decisión de arquitectura. Así que cuando los datos cruzan a un componente del cliente, afecta el tamaño del paquete, el trabajo de hidratación, la serialización y la depuración. Así que debemos tener cuidado con lo que enviamos al lado del navegador. Esto no es una inmersión profunda en seguridad, pero la regla simple es que si los datos cruzan a un componente del cliente, trátalo como visible para el navegador. Así que el segundo patrón se llama transmisión sin cascadas.

Así que si ves en la parte superior, tenemos un await secuencial. Un viaje en este caso, un viaje toma 100 milisegundos, digamos, y luego las recompensas esperan después de eso y la pantalla del hotel, la sección del hotel espera después de eso y luego el HTML se envía solo al final. Así que el problema no es en este ejemplo no solo que los hoteles son lentos, el problema más grande es que todo espera por la sección del hotel. Así que en la parte inferior, la transmisión cambia el comportamiento.

La consulta del viaje termina, la carcasa HTML puede ser enviada y las recompensas y hoteles pueden resolverse independientemente. La consulta lenta puede seguir siendo lenta, pero ya no bloquea la carcasa. Aquí el punto es que las secciones rápidas no deben esperar por las secciones lentas en una página. Así que esta es la versión visual del modelo de transmisión.

Así que digamos que en el paso 1, la carcasa aparece, el encabezado del viaje y el resumen ya son visibles. Y en el paso 2, las recompensas se transmiten después de la carcasa. En el paso 3, los hoteles llegan más tarde. Así que aquí el punto importante es que suspense no solo está cargando un spinner, sino que suspense es un punto de control de renderización. Así que estamos decidiendo qué bloquea la carcasa, mientras que qué puede llegar más tarde.

Así que aquí está el código. Así que este es el corazón del patrón de transmisión. Así que en este código podemos ver que esperamos el viaje porque la carcasa lo necesita. Como lo necesitamos para renderizar. Luego comenzamos la sección de recompensas y hoteles como las promesas. No las esperamos inmediatamente. Eso significa que el trabajo comienza temprano, pero no bloquea la carcasa. Así que solo esperamos que los viajes se carguen y luego las cosas restantes, la recarga asíncrona.

Así que el patrón es simple. Esperar la dependencia de la carcasa y luego comenzar el trabajo secundario temprano. Y dejar que suspense maneje las secciones más lentas. Como puedes ver, solo estamos esperando el próximo viaje, pero estas recompensas y luego las secciones del hotel se cargarán de manera asíncrona. Así que si comenzamos el trabajo temprano, no bloqueamos todo. Así que ahora estas promesas se pasan a los límites de suspense en este ejemplo. Así que cada límite tiene su propio fallback. Recompensas como un esqueleto de recompensa, hoteles como un esqueleto de hotel. Así que esto le dice a React, muestra la carcasa, ahora muestra el fallback para esta sección y revela el contenido real cuando la promesa se resuelva. Así que la parte importante no es el esqueleto. La parte importante es la resolución independiente.

Así que en este caso, las recompensas y los hoteles no necesitan bloquear el resto de la página. Así que aquí suspense decide qué puede llegar más tarde. Así que la tercera parte es el contrato de hidratación. Así que el HTML renderizado por el servidor debe coincidir con la primera renderización del cliente. Así que si el servidor produce una cosa y el cliente produce algo diferente durante la hidratación, React tiene que reconciliar una página que ya es visible. Así que eso puede crear un comportamiento confuso.

Así que en este caso, las causas comunes son típicamente el tipo de ventana, las APIs del navegador, new date, math.runRandom, extensiones y el rasgo de CSS en JS. Así que aquí el mensaje clave es que las discrepancias de hidratación son errores. No debemos ignorarlos. Si ves en el diagrama el HTML del servidor y la primera renderización del cliente, deben coincidir. Así que aquí hay dos ejemplos comunes. Así que el primero es la discrepancia de new date. Así que está relacionado con la fecha y hora, que puede producir un valor en el servidor, mientras que otro valor en el navegador.

Así que el segundo, el segundo ejemplo común es la bifurcación solo en el navegador. Así que digamos que tenemos un chequeo del tipo de ventana, que puede hacer que el servidor renderice una salida y el cliente renderice otra salida. Así que las APIs no son el problema. El problema es cuando la primera renderización del cliente no coincide con la salida del servidor. Así que en este caso, la solución es simple. Así que necesitamos coincidir primero, luego actualizar después de la hidratación. Así que si coincidimos primero y actualizamos después de la hidratación, entonces evitamos esos problemas comunes.

Así que este es el patrón de tiempo seguro, ¿verdad? Entonces, la forma en que podemos hacerlo seguro es básicamente comenzando con el tiempo como nulo. Eso nos da una primera renderización estable, luego dentro de use effect después de la hidratación, leemos el tiempo local real y actualizamos la UI. Así que el servidor y la primera renderización del cliente pueden coincidir. Después de eso, el navegador puede mostrar la hora real. La solución no es nunca mostrar la hora. La solución es actualizarla después de la hidratación. Así que en este caso, tendremos un tiempo de carga hasta que el tiempo esté disponible, y luego renderizamos la hora real.

Así que este es uno de los mayores malentendidos. Muchos de nosotros pensamos que type of window no es igual a undefined para evitar los fallos del servidor, pero esa parte está bien. Puede evitar que el código se ejecute en el servidor, pero no garantiza la seguridad de la hidratación. Así que aquí el servidor puede renderizar el tema claro, pero el cliente puede leer el almacenamiento local y renderizar otra cosa, que puede ser un tema oscuro. Eso significa que la primera renderización del cliente puede ser diferente de la salida del servidor. Así que type of window evita un fallo, pero no evita automáticamente una discrepancia. Así que esta es la mejor versión. Así que comenzamos con un valor predeterminado estable, que es claro para que sea igual en ambos lados. Luego, después de la hidratación, leemos el almacenamiento local dentro de use effect.

Así que la primera renderización puede coincidir, luego el valor específico del navegador se aplica de manera segura. Así que este es el mismo patrón de nuevo. Coincidimos primero, luego actualizamos después de la hidratación. Así que aquí, el estado del navegador pertenece después de la hidratación. Ahora pasemos de estas diapositivas a una demostración local. Así que esta es una app preconstruida de Next.js, sin codificación en vivo, pero te mostraré el panel, del que hemos hablado hasta ahora. En el panel, hay tres rutas. Lo que cambia es el comportamiento de renderización. Así que tendremos tres versiones. Así que la versión uno es una cascada del lado del cliente.

Y la versión dos es límites del servidor primero. {{^}}Y la versión tres es streaming con suspense. Mientras muestro la demo, necesitamos observar tres cosas. Cuando aparece el contenido, qué sucede en la pestaña de red, y cuándo el botón de guardar se vuelve usable. Así que aquí está la aplicación, la aplicación de demostración que tengo en mi local. Esta es la aplicación Next.js. Tengo todo configurado con la pantalla del panel con tres versiones. Déjame ejecutar la aplicación. Así que sí, va a ejecutarse en localhost 3000, que está corriendo aquí. Así que voy a continuar. Así que esta es una aplicación simple, una pantalla de panel con las tres variaciones, tres versiones. Así que entraremos en cada versión. Pero antes de eso, déjame abrir la pestaña de red.

Así que primero tocaré en la cascada del lado del cliente, donde realmente hacemos las llamadas API para cada solicitud. Y luego esperamos por el cliente. Esperamos en el lado del cliente. Así que sí, estoy haciendo clic aquí. Así que como ves, verás que la página se renderiza y luego espera por estas recompensas, hoteles y luego hoteles, y hay esta cosa múltiple que es una parte conocida. Pero sí, si puedes ver, si actualizo de nuevo, verás que es una pantalla de carga luego realmente el cliente se renderiza después de que todo se obtiene. Así que lo mismo, también lo verás en los registros, ¿verdad? Así que obtiene todo y luego el cliente está listo.

Ahora déjame limpiar esto, iremos a la siguiente versión, que es la segunda versión, que es límites del servidor primero. Déjame limpiar esto. Y luego podemos ver que los límites del servidor primero realmente esperan que la página obtenga todo y luego renderiza, renderiza toda la página de una vez. Así que eso también lo puedes ver aquí. Así que obtenemos el panel V2 y luego comenzamos la renderización del servidor obteniendo todos los datos, que son datos de viaje, datos de recompensas, recomendaciones de hoteles, y luego renderiza el HTML. Así que esto es de lo que estábamos hablando en el segundo patrón, pero mientras que en el tercer patrón, así que obtenemos lo que se necesita para renderizar el shell y luego obtenemos el resto de Cindy de forma asíncrona.

Así que permíteme repasar el streaming con suspense. Entonces, como ves, el primer viaje se cargó primero, pero después de eso ves que hay estos hoteles y luego la transmisión de recompensas más tarde, pero fue rápido. Así que déjame actualizar algunos tiempos del retraso para que puedas ver realmente el streaming con suspense en efecto. Así que ahora refresca la página. Sí, ves que esto se cargó y ahora lentamente estas secciones de informes y hotel se renderizan de forma asíncrona y también verás lo mismo aquí. Así que obtienes un panel V3 y luego comenzamos la renderización del servidor obteniendo datos de viaje, datos de viaje listos, y luego tenemos el shell de streaming y luego obtendremos los datos restantes. Así que esto es de lo que estaba hablando en todos estos tres patrones. Estaba hablando de todos estos tres patrones.

Así que ahora déjame volver a las diapositivas. Así que bien. Así que si vuelves, aquí está la lista de verificación de depuración en producción. Así que estos problemas, estos problemas generalmente caen en tres categorías. Primero, desajuste de hidratación. Así que necesitamos verificar valores inestables como fecha, math random, tipo de ventana, y listado HTML también reproducir sin extensión. Y el segundo, cascadas, busca await secuenciales, comienza el trabajo independiente temprano, verifica si los límites de suspensión están en el lugar correcto, observa la transmisión de la red. Y el tercero, se siente lento, pero mide INP, marca puntos de hidratación, perfila tareas largas, mantén los contornos ligeros. Así que la idea clave es simple, depura la fase, no solo el componente. Y esta es la principal conclusión de arquitectura.

Así que la renderización ya no es solo un detalle a nivel de componente, es una decisión de diseño. Antes de construir una ruta, deberíamos hacer cinco preguntas. ¿Qué puede renderizarse en el servidor? ¿Qué debe hidratarse en el cliente? ¿Qué puede transmitirse más tarde? ¿Qué debe ser interactivo inmediatamente? ¿Y qué datos son seguros para cruzar el límite? Si respondemos estas preguntas temprano, la aplicación se vuelve más fácil de razonar, más fácil de depurar y mejor para los usuarios. Así que cerraré con la idea principal. Visible no es lo mismo que confiable, renderizado no es lo mismo que interactivo, transmitido no es lo mismo que hidratado. El objetivo no es hacer que cada página sea completamente renderizada por el servidor o completamente renderizada por el cliente. El objetivo es hacer que cada parte de la página sea honesta sobre cuándo se renderiza, cuándo se transmite, y cuándo se hidrata, y cuándo los usuarios pueden realmente confiar en ella. Así que sí, eso es todo sobre esta charla. Gracias, gracias a todos.