React Performance with Server Components

Hola a todos. Mi nombre es Aurora. Soy desarrolladora web de Noruega y trabajo como consultora en Enmeta en Oslo. Y estoy emocionada de hablar hoy de forma remota en React Summit US, porque estaré enseñando cómo elevar la velocidad, la interactividad y la experiencia del usuario con componentes de React.

Y voy a estar codificando algo inspirado en una característica que he construido para mi proyecto de consultoría actual donde estoy usando activamente componentes de React. Así que esto es una especie de gestor de tareas de proyecto. Y la configuración aquí es el enrutador de la aplicación Next.js. Y luego estoy usando Prisma como mi ORM y una base de datos Azure SQL, y Tailwind para CSS.

Y lo que notarás con esta aplicación es que tiene una carga inicial muy lenta aquí. Y eso es porque he ralentizado las búsquedas de datos a propósito. Pero una vez que la aplicación está cargada, en realidad no está tan mal. Puedo navegar entre estas pestañas muy lentamente, y puedo buscar aquí usando un formulario simple, usando una solicitud get para enviar parámetros al enrutador. Y estos son todos componentes del servidor, lo que significa que no se envía JavaScript al cliente para estos componentes. Y es solo HTML y enlaces y un formulario. Y las cosas funcionan en realidad sin JavaScript. Este es un buen caso base porque funcionará incluso si estamos en un dispositivo con un bajo poder de procesamiento que no puede ejecutar JS efectivamente.

También voy a revisar las puntuaciones de Lighthouse para esta aplicación. Así que como verás, correspondiente a esta baja carga inicial, tengo un primer renderizado con contenido grande, y un índice de velocidad que están en 3.5 segundos, lo cual no es muy bueno. Y puedes ver el impacto de estos aquí. Y eso es porque, como puedes ver en la tira de película aquí, estoy cargando. Estoy esperando que todos los componentes del servidor se rendericen en el servidor antes de mostrar cualquier cosa. Sin embargo, debido a eso, también tengo un cambio de diseño acumulativo de cero. Así que eso es realmente bueno porque no hay inestabilidad visual aquí. Y un tiempo total de bloqueo de cero porque no hay JavaScript para bloquear el bucle aquí. Así que las métricas generales son bastante malas, pero no las peores porque tenemos un buen TBT y cambio de diseño acumulativo. Pero por supuesto, la aplicación no se siente muy bien.

Así que déjame también revisar rápidamente el código aquí. Y el componente más importante es el diseño aquí. Y es un componente del servidor. Así que puede ser asíncrono y puede buscar asíncronamente la información del proyecto y el resumen de tareas de mi base de datos aquí.

Y solo estoy trayendo la base de datos. Y también se ha ralentizado y usando algunas cookies para hacer esto dinámico. Y esto ahora se está utilizando para renderizar una información del proyecto, algunas pestañas de estado. Y luego también tengo una propiedad children aquí, que corresponde a mi página TSX dentro del dinámico. Y esto está usando la pestaña y la búsqueda para directamente dentro del componente del servidor, consultar la base de datos y obtener los resultados filtrados aquí. Así que de nuevo, estas son solicitudes dinámicas. Si hubiera sido estático, sería realmente fácil. Pero como es dinámico, queremos, o tenemos que esperarlo en tiempo de ejecución en el servidor aquí.

Así que básicamente lo que quiero hacer es elevar la velocidad, interactividad y experiencia del usuario de esta aplicación y mejorar los web vitals que son malos sin empeorar los buenos. Y comencemos mejorando la experiencia del usuario de estas pestañas porque no navegan de inmediato. La razón de esto es que estamos esperando que el componente del servidor termine de renderizar en el servidor antes de que podamos navegar. Así que para solucionar esto, usaré un suspense y me permitirá desbloquear la página y renderizar un fallback. Así que voy a hacer un suspense implícito con un archivo load TSX aquí. Y solo voy a dejar un esqueleto simple. Y ahora estoy renderizando un límite de suspense aquí y puedo navegar libremente por estas pestañas mientras espero que el componente del servidor se transmita. Así que eso es bueno ahora. Sin embargo, todavía estoy bloqueado en la carga inicial aquí durante esos tres segundos y medio. Y eso es porque en mi diseño, estoy esperando el proyecto y el resumen de tareas. Y en realidad estoy ejecutando estos secuencialmente aunque no dependen uno del otro. Así que el primer pensamiento aquí podría ser ejecutarlos en paralelo usando promise all y eso ayudaría, todavía estaríamos bloqueados en la carga inicial por el await aquí. Así que vamos a enviar los datos a los componentes que están usando los datos. Así que vamos a cortar esto y dejarlo dentro de la información del proyecto. Eliminar los props y simplemente ponerlo aquí. Así. Y luego voy a hacer lo mismo para el resumen de tareas. Deshazte de esto y déjalo aquí e impórtalo. Y todavía estaré bloqueado hasta que ponga un límite de suspense aquí alrededor de estos datos dinámicos. Así que voy a hacer eso simplemente obteniendo un div simple que diga cargando, y voy a poner esto también alrededor de mis pestañas de estado aquí. Y lo que verás ahora es que he podido desbloquear la carga inicial con estos fallbacks de suspense y transmitir en los componentes del servidor a medida que se completan. Y cada componente ahora es responsable de sus propios datos, lo que significa que ahora son componibles.

Y también estamos utilizando la carga compartida de cómputo entre el servidor y el cliente al hacerlo de esta manera. Y podemos mostrar algo en la pantalla mientras esperamos que los componentes del servidor se carguen. Ahora, tal vez estés notando que estoy obteniendo esta inestabilidad visual aquí, y eso es cambio de diseño acumulativo. Así que puedo ver que tengo un cambio de diseño acumulativo de 0.06 ahora, mientras que antes era cero. Y eso es una experiencia de usuario muy incómoda. Así que eso significa que tengo que dimensionar mis fallbacks de carga correctamente para que correspondan al contenido que se va a transmitir. Así que puedo simplemente copiar este componente. De hecho, ya he hecho algunos esqueletos aquí. Voy a importar estos esqueletos. Y están dimensionados correctamente. Así que ahora tengo este buen fallback que no distorsiona mi vista aquí. Y volvemos a un cambio de diseño acumulativo de 0 aquí.

Y como puedes ver, al transmitir los componentes del servidor a medida que se completan, en realidad he reducido mi mayor Contentful Paint y mi primer Contentful Paint a 0.1, que es la información del producto aquí.

Continuemos mejorando la experiencia del usuario, porque todavía estamos obteniendo esta incómoda actualización de página completa en la búsqueda, y no estamos viendo la pestaña activa actual. Así que voy a ir a las pestañas de estado. Y voy a obtener los params del hook use params de tu JS y usar la pestaña de los params como, y tengo que hacer de esto un componente cliente ahora, porque estoy tratando de usar este hook.

Así que uso cliente, pero estoy teniendo un problema, y es que no puedo tener un componente cliente async. Así que voy a eliminar el async. Pero ahora ya no puedo esperar mi resumen de tareas. Así que supongo que tengo que volver a poner eso en el layout. Solo ponlo aquí. Pero esto, nuevamente, me bloquearía de obtener este tiempo de respuesta inicial rápido del servidor. Así que en lugar de esperarlo, simplemente lo dejaré sin resolver y lo pasaré a las pestañas de estado como una promesa. Lo llamaré promesa de resumen de tareas. Aquí vamos. Y ahora puedo agregar esta promesa a los props. Y usaré el API de React 19 use para resolver esta promesa dentro del componente cliente y permitir que se suspenda de la misma manera que antes. Para que aún pueda obtener este bonito límite de suspense y transmitir el componente, y también puedo ver la pestaña activa en este componente cliente y navegar entre ellas.

La siguiente tarea aquí sería arreglar la búsqueda. Así que en la búsqueda, voy a agregar una mejora progresiva a este caso base de Node JavaScript con un controlador de cambio. Vamos a necesitar un evento, y también vamos a necesitar un par de otras cosas aquí. Los params nuevamente, y los params de búsqueda esta vez. Params de búsqueda de Next.js, usa params de búsqueda. Y vamos a necesitar el router. Usa router de Next. Navegación. Y voy a usar los params de búsqueda para crear un estado en la URL aquí. Así que crearé algunos nuevos params de búsqueda y los empujaré al cambio del router. Así que estamos usando el estado como nuestra única fuente de verdad. Lo siento, usando la URL como nuestra única fuente de verdad para este filtrado aquí. Y luego también voy a importar los params y usarlos para restablecer el formulario cuando cambie la pestaña vinculando la clave a la pestaña. Y también necesito un valor predeterminado de solo campo de entrada para que sean los params de búsqueda con una consulta.

Y de nuevo, tengo que convertirlo en un componente cliente porque estoy tratando de usar cosas del lado del cliente aquí como hooks. Así que nota lo que verás aquí es que cuando intento buscar algo, estoy obteniendo esto en el cambio, pero no estoy recibiendo ninguna retroalimentación instantánea porque el router, la forma en que funciona, va a enrutar después de que lo que sea que esté en la página termine de resolverse, que es este lento componente de servidor de tabla. Y para al menos rastrear el estado de esta navegación para que pueda ver como usuario que algo está sucediendo, voy a usar una transición de React 18. Y me permitirá marcar algo como una transición no bloqueante con start transition. Y también me devolverá un estado pendiente de esa transición. Y puedo envolver mi enrutamiento de ruta con esta transición y usar el estado pendiente para habilitar un spinner de carga aquí. Para que cuando estemos haciendo la transición a esta nueva página, obtengamos este spinner de carga mostrando el estado de esa navegación. Y debido a que esto es una mejora progresiva, eso significa que si este formulario es hidratado por JavaScript, tendremos este cambio ejecutándose y de lo contrario, será simplemente un formulario simple.

Voy a añadir otro componente aquí, de hecho, porque también quiero tener un filtro de categoría aquí. Y este componente toma una promesa de categorías, leyéndola con use de la misma manera que lo hace el status tabs. Y {{^}}voy a obtener esto aquí dentro del layout. Así que las categorías de getCategories aquí. Ups, debería ser const. Y voy a pasar esto hacia abajo. Y también necesito suspenderlo de nuevo para no bloquear el layout aquí. Así que voy a añadir un suspense y simplemente volver a un botón de toggle deshabilitado simple.

Y luego, con suerte, podré envolver esto correctamente. Introducir el botón de toggle. Y veamos cómo se ve. Tengo esta carga y luego tengo este grupo de botones de toggle aquí para las categorías. Pero de nuevo, cuando hago clic en estos, no obtengo ninguna retroalimentación, y eso es porque estamos esperando que el componente del servidor termine de obtener datos de la base de datos con el filtrado correcto. Así que al menos añadamos un estado de carga a este filtro de categoría. Vamos a usar una transición, de nuevo, de la misma manera que acabamos de hacer con React 18. Añadir una transición alrededor del enrutamiento. Y necesitamos usar asPending de alguna manera. Pero no es tan sencillo porque no quiero hacer que este botón gire ni nada por el estilo. Eso sería un poco excesivo.

Así que en su lugar, voy a usarlo para añadir un atributo data pending a este div si es verdadero. Y en mi layout aquí, de hecho, tengo una clase de grupo en este div que envuelve todo. En la pestaña, estoy usando una pseudo clase has para hacer una animación de pulsación si el grupo tiene una propiedad o un atributo de data pending. Estoy usando solo CSS en lugar de un proveedor de estado global aquí. Así que ahora cuando estoy alternando esto, veré un efecto de pulsación aquí, haciéndome saber que algo está, de hecho, sucediendo dentro de la aplicación. Así que eso es bueno porque puedo mostrar el contenido de venta pero también hacerle saber al usuario que hay una transición en curso.

Pero todavía no estoy contenta con las pestañas porque preferiría que fueran más interactivas de forma natural. Así que para resolver esto, usaremos el hook de React 19, use optimistic. Y tomará un estado para mostrar cuando no hay ninguna acción pendiente. Y vamos a poner esta verdad desde la URL aquí, los amigos de búsqueda allí. Y luego devolverá categorías optimistas y una función para establecer las categorías optimistas. Podemos usar esto como nuestros valores seleccionados. Y podemos configurarlos antes de empujar al enrutador.

Así que estas son las categorías optimistas aquí. Y ahora déjame simplemente refrescar aquí. Lo que sucederá es que use optimistic crea este estado de cliente optimista que se descarta cuando se asienta con la verdad del enrutador aquí. Lo que significa que nuestras categorías son instantáneas y no dependen de la red. Y el crédito es para Sam Zelikoff con su publicación en build UI para este patrón. Es un patrón realmente agradable.

Ahora hay otra cosa que tengo que arreglar porque cuando introduje las categorías, estoy llamando getCategoriesMap aquí. Y de hecho también lo estoy llamando dentro del resumen de tareas para poder mapearlo a las categorías correctas aquí. Así que estoy llamando a esta función dos veces. Y si refrescas, puedes ver aquí que se está llamando dos veces. Y eso no es óptimo. Así que lo que puedo hacer es dirigirme a esta función y envolverla con otra API de React 19 llamada cache. Esta es una función de orden superior que me permitirá reutilizar el valor de retorno de esto. Y no debería estar allí, sino aquí. Voy a importarlo. Y ahora deduplicará esta solicitud ya que se está llamando dos veces en el mismo renderizado.

Y no sé si viste eso, pero el tiempo de carga realmente bajó de 2.7 a 2.2. Y ahora solo se está llamando una vez dentro de la consola aquí. Y estoy deduplicando esta solicitud. Y lo que esto significa como desarrollador es que podemos seguir usando nuestro patrón común de probar datos dentro de los componentes de manera similar a como lo haríamos, por ejemplo, con TensorQuery en una aplicación del lado del cliente, lo cual es agradable. No tienes que aprender un conjunto completamente nuevo de patrones aquí. Hagamos una demostración final aquí.

Voy a eliminar mis filtros aquí para que puedas ver algunas cosas más. Y simplemente eliminar el campo de búsqueda aquí. Así que ahora, cuando cargo esta aplicación, puedo ver el contenido de inmediato e incluso puedo interactuar con las pestañas mientras espero que los componentes del servidor terminen de renderizarse en el servidor y se transmitan. E incluso puedo interactuar con mi filtro aquí mientras hago eso. Y puedo hacer una búsqueda. Y puedo recargar la aplicación y tener el mismo estado exacto debido a que la URL es nuestra única fuente de verdad aquí, lo que significa que el estado de la aplicación es recargable, compartible, y se puede marcar como favorito. Y esto es realmente bastante robusto porque hemos estado mejorando progresivamente el caso sin JavaScript y solo agregamos una pequeña cantidad de JavaScript donde lo necesitamos. Y no hay use effects o use states en esta aplicación porque estamos haciendo aplicaciones interactivas sin ellos en este nuevo mundo de React Server Components.

Finalmente, permíteme revisar los puntajes de Lighthouse. Acabo de ejecutarlo porque toma un poco de tiempo. Lo ejecuté justo antes de la charla. Y he podido mejorar el primer Contentful Paint y el último Contentful Paint al mostrar instantáneamente este encabezado de información del proyecto. Y el índice de velocidad también es mucho mejor porque está mostrando incrementalmente más y más contenido. Así que aunque tenemos búsquedas de datos lentas, estamos obteniendo muy buenos puntajes allí. Y el tiempo total de bloqueo sigue siendo cero, lo cual es bueno, correspondiente a nuestros clics responsivos y baja cantidad de JavaScript y sin tareas largas. Y todavía tenemos un cambio de diseño acumulativo de cero porque dimensionamos correctamente nuestros límites de suspense. Así que mejoramos enormemente el rendimiento, obteniendo un puntaje de Lighthouse de 96 incluso con un tiempo de carga de 2.2 segundos, lo que significa que logramos completar la tarea de mejorar estas malas métricas y mantener las buenas mientras también hacemos que la aplicación sea rápida, interactiva y amigable para el usuario.

Así que eso es todo para esta charla. El código está fijado en mi GitHub. Y puedes seguirme en Twitter si estás interesado en más contenido de RSC. Gracias por escuchar.