Medí el Rendimiento de los React Server Components para que Tú No Tengas Que Hacerlo

Hola a todos. Soy Nadia, y hoy quiero hablar sobre los componentes de servidor de React y el rendimiento. Un poco sobre mí. He sido desarrolladora durante mucho tiempo, y en los últimos años, me he centrado principalmente en el rendimiento del front-end y React. Me encanta investigar cómo funcionan las cosas en esta área tanto que ahora terminé con un montón de análisis profundos e investigaciones, e incluso dos libros sobre el tema de, lo adivinaste, React y el rendimiento.

Y si has prestado atención a las conversaciones sobre React en los últimos años, probablemente hayas escuchado las palabras componentes de servidor mencionadas en el contexto de mejorar el rendimiento. Su principal promesa es simple. Llevar más trabajo al servidor, enviar menos JavaScript, obtener datos antes, y tu carga inicial se vuelve más rápida. Pero, ¿cómo sucede exactamente esto? ¿Y cuánto puedo esperar de mejora en el rendimiento? Esto es lo que quiero descubrir hoy.

Sin embargo, aquí está el truco. No puedo simplemente activar y desactivar componentes de servidor simples para medir lo que quiero. Para entender qué cambian exactamente los componentes de servidor, necesitamos un modelo mental claro de cómo React normalmente renderiza y obtiene datos. Tanto en el cliente como en el servidor, por cierto. Porque aquí está la parte divertida. Ya tenemos el concepto de renderizado en servidor. Y lo tenemos desde hace años. Entonces, ¿cuál es exactamente la diferencia?

Construí una aplicación de una sola página, tu SPA normal, con múltiples rutas del lado del cliente y obtención de datos del lado del cliente como base. Voy a llevar esto a un renderizado básico del lado del servidor y explicar qué cambia en el perfil de rendimiento y por qué. Luego a un SSR más complicado con obtención de datos en el servidor y nuevamente analizar qué cambia y por qué. Y finalmente, convertir la aplicación en los componentes de servidor y mostrarte el resultado. De esta manera veremos qué puedes ganar y qué pagas cuando agregas un renderizado del lado del servidor a una aplicación previamente renderizada en el cliente. ¿Qué puedo esperar si ya tengo SSR y mi framework de repente agrega soporte para componentes de servidor? Y como un bono, ¿qué puedo esperar si ya tengo una aplicación basada en SSR y decido moverme a Next.js App Router, que es el framework más popular en este momento?

Así que aquí está mi aplicación conejillo de indias. Tengo algunas páginas. Ya es muy interactiva. Y para el propósito de las mediciones de hoy, me centraré exclusivamente en la página de la bandeja de entrada. Ya es bastante funcional. Como puedes ver, incluso tiene un editor rudimentario que aparece cuando hago clic en un mensaje y en realidad funciona. Los elementos en la barra lateral se obtienen de un endpoint bastante rápido. Toma alrededor de 100 milisegundos para ejecutarse. Una lista de mensajes se obtiene de un endpoint bastante lento. Toma alrededor de un segundo para ejecutarse. Voy a usar Chrome DevTools hoy para medir la carga inicial. Si nunca lo has hecho, abre el perfil de rendimiento en DevTools, haz clic en recargar, espera un poco y luego haz clic en finalizar. Te dará esta imagen grabada. Voy a estar mirando principalmente lo que está sucediendo en el panel de red. Y las métricas que me interesan hoy son cuando la página se vuelve visible, lo que corresponde a la métrica en Chrome llamada LCP, Largest Contentful Page, Paint. Cuando los elementos de la barra lateral se vuelven visibles, está en algún lugar aquí. Y luego cuando los mensajes mismos se vuelven visibles, en algún lugar aquí. Y finalmente, voy a usar esos ajustes para imitar dispositivos más lentos e internet más lento y deshabilitar la caché de red para imitar la primera vez que el usuario abre la página cuando aún no hay caché en el lado del navegador.

Bien, eso es suficiente de configuración. Vamos finalmente a investigar y medir cosas. Primero, comencemos con la línea base, el renderizado del lado del cliente. ¿Qué es exactamente? Desde un punto de vista de implementación, significa que cuando tu navegador solicita esta página de bandeja de entrada, el servidor responde con HTML que se ve así. El horror. Pantalla completamente vacía.

Pantalla completamente vacía. Para transformar este div vacío en una página hermosa, el navegador tiene que hacer un montón de trabajo antes de que veas algo. Descarga CSS y JavaScript. Analiza y ejecuta el JavaScript. Luego React se inicia, y solo entonces ves la interfaz de usuario aparecer en la pantalla. Y eso ni siquiera es el final. Después de eso, React inicia la obtención de datos. Esperas en la red. Y luego, cuando los datos regresan, React vuelve a renderizar y reemplaza los marcadores de posición por contenido real.

Si grabo el rendimiento de mi aplicación ahora, veo este perfil, que es prácticamente idéntico a lo que acabo de mostrarte. Y los siguientes números son nuestro rendimiento. Toma alrededor de cuatro segundos antes de que el usuario vea absolutamente algo, luego otros 600 milisegundos para ver la barra lateral, y otros 400 para los mensajes. Lo cual se ve un poco meh. Creo que estarías de acuerdo. En la vida real, sin embargo, hay múltiples maneras, por supuesto, de mejorarlo. Como reducir JavaScript, por ejemplo, y prefetching de datos. Pero el núcleo de este tipo de renderizado permanece exactamente igual.

El momento en que el contenido aparece en la pantalla depende completamente de JavaScript. Debido a esto, no es tan ideal para los números de carga inicial. Además, la indexación de búsqueda y los bots de redes sociales no suelen estar tan contentos con HTML vacío como contenido. Así que esto es lo que inició el auge de los frameworks SSR y generadores de sitios estáticos para React hace mucho tiempo. La idea con ellos es simple. En lugar de enviar un contenedor vacío y pedirle al navegador que construya todo, como está sucediendo aquí, renderizamos la página a HTML en el servidor primero. Este renderizado es literalmente solo una llamada de función y luego reemplazo. Nada más. Solo necesitamos extraer ese HTML de React e inyectarlo en el div vacío así.

Si hago este cambio en mi aplicación, se convierte en renderizado del lado del servidor. Ahora tenemos un HTML significativo. Así que el sitio se vuelve visible cuando el CSS, que es un recurso crítico, se descarga. Y ya no hay necesidad de esperar por JavaScript para eso. Sin embargo, todo lo demás permanece exactamente igual. El paquete de JavaScript en sí no cambia, y el navegador todavía necesita hacer todo lo que hacía antes, incluyendo adjuntar manejadores de eventos y asegurarse de que el sitio siga disponible.

Mientras esperamos por todo el JavaScript, la página ya es visible, pero nada de lo que se supone que debe funcionar realmente funciona. No hay interactividad. Este toggle, por ejemplo, habrá un período en la página cuando hago clic en él y no pasa nada. Esta brecha es la prioridad de la página. Hay otro inconveniente. La obtención de datos. En esta versión, ayuda tener un poco más de flexibilidad. Pero nada de lo que se supone que debe funcionar realmente funciona.

No hay interactividad. Este toggle, por ejemplo, habrá un período en la página cuando hago clic en él y no pasa nada. Esta brecha es el precio que pagas por las grandes ganancias de carga inicial con SSR. Hay otro inconveniente. La obtención de datos. En esta versión, todavía se ejecuta en el cliente como un efecto secundario, por lo que esos dos números relacionados con los datos permanecen exactamente donde estaban. Pero, ¿tienen que hacerlo? Ya estamos en el servidor, así que ¿por qué no obtener eso allí para que el HTML se envíe con contenido real en lugar de solo marcadores de posición? Eso seguramente sería más rápido. Esto también es posible.

En el servidor, necesitaremos esperar por estos datos. Así, simples promesas. Luego pasar estos datos a React como props normales. Luego un poco de trabajo en la parte superior, que no voy a mostrarte, y finalmente funciona. El perfil de rendimiento se mueve a ser así. El número inicial, el LCP, se desplaza ligeramente hacia más tarde, ya que ahora tenemos que esperar a que las promesas se resuelvan en el servidor. Pero la espera del lado del cliente desaparece, y toda la página es visible de inmediato sin ningún estado de carga molesto. Los números para esta situación son así para comparación, lo cual es una imagen bastante interesante.

Sin embargo, el caso de la obtención de datos es cuando comienza a complicarse implementarlo manualmente. Como mínimo, necesitarías implementar el enrutamiento en el servidor y alguna idea de diferentes puntos de entrada, para que no obtengas mensajes en páginas cuando no son necesarios. Así que en este punto, probablemente usarás algún tipo de framework LCSR. Independientemente del framework y su implementación, el perfil de rendimiento se verá exactamente igual. La diferencia estará en cómo el framework maneja la carga de JavaScript y CSS, y eso es todo.

Por ejemplo, si migro de mi solución simple personalizada al enrutador de páginas de Next.js, la versión antigua de Next.js, el perfil cambiará de esto a algo como esto. Serán más archivos JavaScript al mismo tiempo, por lo que será una carga de CSS ligeramente más larga y un LCP ligeramente peor. Con AppRouter, el Next.js más nuevo, en modo SSR sin ningún componente del servidor, se verá algo así. La carga de JavaScript se retrasará, por lo que la carga de CSS es ligeramente más rápida, y el LCP es la cantidad más corta allí. Los números para los tres con y sin obtención de datos son estos.

Como puedes ver, la versión de AppRouter tiene el mejor LCP debido al JavaScript retrasado, pero todo lo demás se retrasa exactamente por la misma razón. Además, comparar los números de esta manera muestra cuánta diferencia puede tener la forma en que estás dividiendo el código y obteniendo recursos críticos. Eso es SSR, y como podemos ver, SSR es bastante genial para la carga inicial. Todavía hay dos problemas con ello que podrían molestarte. Primero, la cantidad de JavaScript que descargamos y la brecha de interactividad debido a ello.

¿Realmente necesitamos todo este JavaScript aquí? Si miro el componente de navegación, por ejemplo, es principalmente marcado, así que son divs, enlaces, clases, exactamente cero interactividad. Todo esto todavía se envía en paquetes de JavaScript. Todo esto todavía se considera React. La única razón, sin embargo, por la que este código no es utilizado por muchas personas es porque no es un componente de JavaScript.

Todo esto todavía se considera React. La única razón, sin embargo, por la que este código está allí es porque React necesita entender todo el árbol de todos los componentes para construir un DOM virtual, para mapear el DOM virtual a lo real que ves en la pantalla. En cualquiera de las implementaciones de SSR, el proceso de extraer este árbol de la aplicación React ocurre dos veces, primero en el servidor y luego en el cliente. Aquí es donde entran los componentes del servidor.

La idea es esta. ¿Qué pasaría si sacamos este componente del paquete de JavaScript y luego lo mantenemos en el servidor y en su lugar generamos algunos datos, como un árbol, del cual React puede luego recrear el DOM virtual y comenzar a trabajar como de costumbre sin intentar construir el árbol por sí mismo en el cliente? Enviaremos esta carga generada junto con HTML, reduciendo así la cantidad de JavaScript enviado al navegador. En teoría, esto podría ser enorme para los tamaños de los paquetes. Imagina si este componente necesita alguna biblioteca pesada para generar este diseño, por ejemplo. Si se implementa como un componente del servidor, todos estos megabytes de datos permanecerán en el servidor y la biblioteca nunca llegará al cliente.

En la práctica, podemos simplemente probarlo. Ya migré al enrutador de aplicaciones de Next.js, que es totalmente compatible con los componentes del servidor. Así es como se ve el rendimiento de mi aplicación cuando todo son componentes del cliente, lo que significa que todo ha usado client en la parte superior. Todo está incluido en el paquete, por lo que es prácticamente una experiencia SSR, una normal. Todo lo que necesito hacer para convertir esto en componentes del servidor es eliminar UseClient de la raíz de las páginas y luego usarlo en los componentes finales que realmente necesitan interactividad, por lo que componentes con estado, por ejemplo. Hice todo eso, un poco de refactorización en mi aplicación, y luego este es el resultado.

La página de inicio de sesión estática se redujo de 46 kilobytes a casi nada, lo cual es bastante genial porque muestra que funciona. Otras páginas cambiaron solo un poco. Los fragmentos compartidos no cambiaron en absoluto, por lo que todas las bibliotecas comunes todavía se envían al cliente. Y luego la página de mensajes, la que me importa, tampoco cambió en absoluto, desafortunadamente. Esto es bastante decepcionante. Como puedes imaginar, esto tuvo exactamente cero impacto en mis mediciones para esta página. Así que esta es la primera conclusión sobre los componentes del servidor. En aplicaciones mixtas donde tienes algunos componentes del cliente y algunos componentes del servidor, los componentes del servidor por sí solos pueden apenas tocar tu paquete. Ves verdaderas ganancias principalmente en páginas completamente estáticas donde todo puede ser solo del servidor desde el principio.

Ves verdaderas ganancias principalmente en páginas completamente estáticas donde todo puede ser solo del servidor desde el principio. Sin embargo, esta no es el final de la historia. Hay otro aspecto que investigar. ¿Recuerdas este flujo clásico de SSR de antes? Iniciamos una búsqueda en la parte superior, luego esperamos a que termine. Pasamos estos datos a React. Renderizamos a HTML y enviamos ese HTML al navegador. Pero, ¿y si nuestro servidor pudiera ser más inteligente?

Técnicamente, no necesitamos esperar a que todas las promesas comiencen a hacer otra cosa. ¿Y si en su lugar pudiéramos activar esas búsquedas como aquí? Renderizar y enviar las partes de la aplicación que no necesitan estos datos de inmediato. Lo llamamos camino crítico. Cuando llegan los datos de la barra lateral, renderizar los elementos de la barra lateral y enviarlos. Y luego hacer exactamente lo mismo para los mensajes. Lo que describo es exactamente lo que obtienes cuando combinas la idea de componentes del servidor con streaming. Desde el punto de vista de la implementación, se ve así. Tenemos componentes del servidor, y esos ahora pueden ser asíncronos.

Así que este código se convierte en esto. Y también se vuelve completamente válido y de hecho recomendado para la búsqueda de datos porque de lo contrario no funcionará. Además, en lugar de esta espera sincrónica para todo, el servidor utiliza un stream render-to-pipeable. Que es compatible con los streams de Node para emitir HTML y la carga útil de los componentes del servidor en fragmentos. Tan pronto como cada fragmento está listo, ya no hay necesidad de esperar por promesas. Se emiten al navegador. Como puedes ver, la búsqueda de datos desaparece aquí por completo. Ahora vive en el componente asíncrono. Esto es exactamente cómo funciona en el enrutador de aplicaciones de Next.js, por ejemplo. Simplemente está oculto de nosotros.

Todo lo que necesito para aprovechar esta elegante implementación es hacer un poco de refactorización de mi parte. Primero, como ya viste, necesito deshacerme de todo el estado y toda la carga. Y hacer que el componente sea asíncrono y obtener datos directamente en el componente del servidor. Segundo, debo asegurarme de que este componente sea realmente un componente del servidor, y esta parte es la más difícil. Así que React UI, como probablemente sepas, árboles anidados. Así que mi aplicación, por ejemplo, tiene una barra lateral de diseño que compone la página de la bandeja de entrada, que tiene un montón de componentes incluyendo contenido y así sucesivamente.

Si pongo UseClient en cualquier parte de la parte superior de esta jerarquía, todos esos componentes se convierten en componentes del cliente. Y los componentes del cliente no pueden ser asíncronos y no pueden obtener datos en el cuerpo de renderizado sin causar bucles infinitos. Así que al reescribir la obtención de datos, necesito tener mucho cuidado de no convertir accidentalmente ninguno de los componentes en la jerarquía en componentes del cliente. Y finalmente, necesito envolver partes de la aplicación en un componente especial llamado suspense. Los límites de suspense son cómo React decide los fragmentos de streaming. Sin ellos, React trata todo el árbol como un fragmento crítico, espera por todo, y terminas con el mismo perfil de bloqueo que teníamos en el SSR clásico.

Así que digamos que durante mi migración, me olvidé de suspense, lo cual sucede bastante porque no todos entienden cómo funciona todo esto. El resultado final será exactamente el mismo que tenía con el modo SSR cuando obtenía los datos a nivel de página. Si agrego suspense correctamente, se transforma mágicamente en esto. El perfil registrado se vería así si lo estiro un poco más con endpoints más lentos. De lo contrario, como viste, son exactamente los mismos números porque probablemente Next.js o React agrupan esos fragmentos juntos si son bastante rápidos. Así que ves cómo la barra de HTML corre casi hasta el final del rastro. Este es el servidor que estoy usando. La barra de HTML corre casi hasta el final del rastro. Este es el servidor que mantiene la conexión abierta y transmite fragmentos a medida que cada límite protegido por suspense está listo. Esos son todos los números juntos dentro del mismo marco para comparación.

Y ahora finalmente unamos todo esto. Entonces, client-side rendering. El navegador obtiene un contenedor vacío, descarga un montón de JavaScript, inicia React, y finalmente obtiene los datos. El rendimiento es decepcionante en este caso. El simple server-side rendering mejora mucho los números de carga inicial, pero nada más. Además, introduce un vacío cuando la UI es visible, pero aún no es interactiva. Obtener datos en el lado del servidor puede cambiar drásticamente esos números, pero a costa de una degradación en el número inicial. Así que será ligeramente importante. El vacío permanece intacto ya que no hay cambios en el JavaScript.

Luego, añadiendo server components a la mezcla. La reducción del tamaño del bundle también es decepcionante y probablemente será así para cualquier mezcla con server y client-side rendering. La única vez que el bundle se reduce significativamente es para las páginas que son muy estáticas con muy poca interactividad. Las verdaderas ventajas con los server-side components aparecen cuando re-arquitectas toda la aplicación para obtener datos primero en el servidor. Y esta es la parte crucial. No olvides el suspense para habilitar el streaming. Aquí es donde el perfil de rendimiento cambia radicalmente. Comienzas a enviar HTML útil temprano y mantienes la conexión abierta para transmitir el resto de los fragmentos. Los fragmentos están protegidos por suspense, como mencioné, y nada más.

No es suficiente hacer que los componentes sean asíncronos para ver mejoras en el rendimiento. Si vale la pena el esfuerzo o no, por supuesto, depende de ti. Si quieres leer toda esta investigación con más detalle y jugar con el código tú mismo, de hecho lo tengo en forma de artículo. Así que por favor revísalo. Gracias por escuchar. Espero que hayas disfrutado la charla. Y si tienes alguna pregunta, no dudes en contactarme. Haré mi mejor esfuerzo en cualquier red social. Gracias.