Concurrencia en React × Core Web Vitals

Empiezo esta charla con malas noticias. Este es el informe de PageSpeed Insights para newyorktimes.com, escrito en React. Tiene todas sus métricas de velocidad en verde, excepto para InteractionToNextPaint.

Este es el informe de PageSpeed Insights para target.com, también escrito en React. También tiene todas sus métricas de velocidad en verde, excepto para InteractionToNextPaint.

Este es el sitio web de Notion. También tiene todas sus métricas de velocidad en verde, excepto para InteractionToNextPaint. Esta métrica, InteractionToNextPaint, es una nueva métrica de performance introducida por Google. Mide la rapidez de los clics o las entradas de teclado en la página. En casi todas las aplicaciones de React que he visto hasta ahora, esta métrica es amarilla o roja. Lo que significa una mala user experience, y también significa que, a medida que esta métrica se convierte en un vital central en marzo de 2024, eso también significa que en unos pocos meses tu jefe y tu equipo de marketing también se darán cuenta de repente de que esta métrica es amarilla o roja.

Ahora, ¿quién aquí ha trabajado con esta métrica antes? ¿Alguien ha intentado depurarla o optimizarla? En realidad, no puedo ver nada desde aquí debido a las luces. Bueno, está bien, vamos a hacer una inmersión rápida en la teoría.

Entonces, la idea central detrás de esta nueva métrica es que te dice cuán lenta es tu aplicación. Y cuando ves una interacción hasta el siguiente punto de, por ejemplo, 393 milisegundos, aquí es cómo se calcula. Primero, cuando abres cualquier aplicación o sitio web en tu Chrome, Chrome mide cada clic o pulsación de tecla que haces en la página y encuentra el más lento de ellos. Luego, Chrome toma ese valor más lento y lo envía a los servidores de Google diciendo, hey, para esta sesión el valor INP fue, por ejemplo, 500 milisegundos, lo que significa que el clic o la pulsación de tecla más lenta en la página fue de 500 milisegundos. Y luego, a medida que más usuarios visitan la página y hacen los clics y envían sus valores INP, Google hace la magia de las estadísticas y calcula el INP general para todas las visitas. Así que eso es lo que es INP. Fin de la teoría. Veamos cómo se ve en la práctica. Así que aquí hay una aplicación muy básica de toma de notas. Podrías abrir una nota, podrías escribir en una nota, soporta markdown, podrías crear una nueva nota y también podrías filtrar notas. Y la acción de filtrar notas, es bastante lenta. Así que, aquí en esta esquina, podrías ver esto barra giratoria, que es un spinner, que muestra cuando la aplicación es responsive. Así que, cuando el spinner gira, eso significa que la aplicación es responsive. Cuando el spinner se congela, eso significa que la aplicación también está congelada. Y si intento escribir en este input de filtro, podrías ver que en el momento en que escribo, el spinner se congela durante medio segundo o un segundo. Esto significa que escribir en el filtro es muy poco responsive, puedo sentirlo, y la página se congela durante ese período de tiempo. Así que eso es acerca de la user experience. Y esto también empeora la interacción con una métrica expandida.

Ahora, hay una forma muy fácil, hay una forma muy sencilla de ver cómo exactamente la interacción con una métrica expandida se ve afectada por esto. Para ver esto, voy a ir a la Chrome web store, voy a encontrar la extensión de web vitals, la voy a instalar en Chrome. Voy a abrir sus opciones, habilitar el inicio de sesión en la consola, y luego abrir la consola en mi página. Y ahora, si recargo la página, y si miro en la consola, vería cada core vital, cada métrica de performance de la página de la aplicación registrada en la consola. Y si intento interactuar con la aplicación, como, por ejemplo, seleccionando algún texto, o simplemente haciendo clic en algunos lugares aleatorios en la página o abriendo notas, vería cuánto tiempo tomó cualquier interacción en la página. Quiero decir, tomó. Y si intento escribir en el input de filtro, vería que escribir en el filtro es muy, muy lento. La interacción toma 500, 600 milisegundos y eso resulta en un INP rojo. Y también puedes ver cómo cuanto más interactúo con la página y peor se vuelve el tiempo de interacción el valor de INP también aumenta. Como INP es simplemente la interacción más lenta que ha ocurrido en la página, ¿verdad? Así que podrías ver que cada vez que hago una interacción que se vuelve aún más lenta

Entonces, vaya, fue en la dirección equivocada. Aquí está el código de mi aplicación. Este es el componente de la lista de nodos que es responsable de esta barra lateral que tengo a la izquierda. Y tiene dos cosas grandes en él. Tiene el componente de entrada de filtro, que es este componente. Tiene la lista de nodos, que es esta lista de nodos, esta enorme lista de todos los 1,500 nodos que tengo en la aplicación. Y tiene el estado del filtro, que controla tanto las entradas del filtro como la lista de nodos.

Y ahora, en esta aplicación, cada vez que escribo en la entrada del filtro, el estado del filtro se actualiza, y esa actualización de estado se considera urgente. Así que React tiene que tomar esa actualización de filtro y tiene que renderizar todos los componentes de una vez. Escribo, y es lento. ¿Verdad? Entonces ahora, con React-TT, con la concurrencia de React, lo que puedo hacer es tomar esta actualización de estado y decirle a React que, oye, algunas partes de esta actualización de estado no son urgentes. Y aquí es cómo voy a hacer esto. Así que lo primero que voy a hacer es que voy a tomar este único estado y dividirlo en dos bits. Así que voy a llamar al primero entrada de filtro. Y al segundo valor de filtro. En segundo lugar, voy a tomar estos dos bits de estado separados y voy a hacer que controlen diferentes partes de la interfaz de usuario. Así que la entrada de filtro va a controlar mi entrada de filtro, obviamente. Y el valor del filtro va a controlar mi lista de nodos. Y ahora también necesito actualizar ambos estados cuando escribo en la entrada del filtro y eso cambia. Así que simplemente voy a hacer esto. Voy a recibir el valor y voy a llamar a set filter input, set filter value. Gracias, Copilot.

Bien, así que tomé un bit de estado y lo dividí en dos bits de estados y conecté estos dos bits de estado a dos componentes separados. Hasta ahora esto no hace nada, simplemente empeora la aplicación. En lugar de una pieza de estado tengo dos piezas de estado pero la aplicación es todavía lenta, puedes ver que estoy escribiendo, es terrible y básicamente no hace nada más. Pero aquí es donde viene la tercera, la clave, pieza del rompecabezas. Ahora que tengo dos bits de estado que se actualizan independientemente podría tomar el segundo bit de estado que es responsable de toda la lista de Nots y podría decirle a React, oye React, cuando hagas esta actualización de estado, cuando hagas un renderizado que se dispara porque el estado cambió, ¿podrías renderizarlo de forma no urgente? Porque yo como usuario realmente no me importa si los Nots se renderizan de inmediato, ¿verdad? Me importa que el filtrado en el que estoy escribiendo se renderice de inmediato, quiero escribir y quiero ver la letra que escribí de la manera correcta. Pero los Nots, podrían esperar, podrían esperar medio

Ahora, si envuelvo mi SetFilterValue con StartTransition, lo que va a pasar es que voy a escribir en mi entrada de filtro y nada se va a congelar. Así que puedes ver en el panel de la derecha que todas las interacciones se están bloqueando. Son verdes. Y mientras estoy escribiendo en mi filtro, el spinner sigue girando. Nada se congela. La aplicación es completamente receptiva. Puedo escribir todo lo que quiera y es absolutamente rápido. El botón literalmente ha desaparecido. Esto es casi mágico. Bien. Ahora, ¿alguien puede adivinar cómo funciona esto? Esta es una pregunta para la sala. La magia fue la respuesta correcta, sí. Entonces, no, la forma en que esto realmente funciona es devolviendo el control al navegador. React comienza a renderizar la aplicación y luego devuelve el control al navegador después de cada fotograma. Aquí está cómo funciona esto desde la perspectiva de React. Entonces, React tiene una cola de actualizaciones. En nuestro caso, esta cola de actualizaciones tiene componentes que no necesitan ser actualizados

Ahora, should yield to hosts, la función que decide cuándo React debe devolver el control al navegador es básicamente una línea. Simplemente devuelve true si el renderizado actual ha tomado más de 5 milisegundos. Ahora, schedule perform work until deadline function, la función que programa la siguiente porción de actividad de JavaScript, la siguiente porción de procesamiento de la cola de actualizaciones, es también bastante simple. Simplemente llama a set-timeout zero. ¿Quién dijo eso? Yay. Simplemente llama a set-timeout zero para programar la siguiente llamada perform work until deadline o set immediate o message channel si hay usuarios de React dañados. Y eso es básicamente cómo se implementa. Si recuerdas la diapositiva del pasado, así es como React 17 se comportaba cuando intentabas el campo de filtrado. Escribías en el campo. Cambiaba el estado en todos los componentes y luego React tenía que procesar todos los componentes uno por uno. Congelando la página todo el tiempo. Ahora, con React 18, esto cambia. Cuando intento escribir en el campo de filtro, React llama a set-filter input y luego llama a set-filter value. Esto también causa que el estado se actualice en un montón de componentes. Pero ahora, algunas de estas actualizaciones de estado son argent, mientras que otras se marcan como no argent. Y así, lo que React ahora hace es que renderiza las actualizaciones argent de la antigua manera bloqueante, manteniendo la página congelada. Pero luego empieza a renderizar actualizaciones no argent. Las actualizaciones envueltas con start transition de una manera no bloqueante,

Ahora, de lo que hemos hablado hasta ahora era solo una característica concurrente, useTransition. También hay otra característica concurrente, que es menos conocida, y es suspense durante la hidratación de rect. Entonces, si no estás familiarizado con la hidratación de rect, el proceso de hidratación de rect es básicamente un proceso cuando renderizas un sitio en el servidor, luego en el cliente hidratas ese sitio, renderizando de nuevo cada componente de rect, adjuntando oyentes de eventos al DOM ya existente, y luego obtienes el conjunto en vivo. Ahora, la hidratación en mi experiencia es típicamente la operación más costosa de JavaScript que podría tener la aplicación de rect, simplemente porque rect tiene que renderizar cada uno de los componentes que existen en la página, como, por ejemplo, aquí está delivery gastando 1.55 segundos hidratando el sitio con un estrangulamiento de CPU 4x, o aquí está Notion gastando 1.8 segundos, o aquí está Walmart gastando 1.1 segundos, y no pretendo burlarme de este sitio web o de estos equipos. Esto es una situación estándar. Cada sitio de React tiene esto. Así es como funciona la hidratación de rect. Y lo que esto significa para la interacción hasta el Próximo Pintado es que, si haces clic en algún lugar de la página durante la hidratación, entonces el navegador no procesará ese clic y no repintará esa pantalla hasta que se complete la hidratación porque el navegador está simplemente bloqueado ejecutando la hidratación, y eso podría suceder. La hidratación podría terminar medio segundo o un segundo después. Entonces eso resulta en un tiempo terrible de interacción hasta el Próximo Pintado, pero lo que React18 ahora te permite es tomar tu sitio e hidratarlo de manera concurrente. De la misma manera que use transition funciona para las interacciones, suspense funciona para la hidratación. Para hacer esto, necesitas tomar tu página, como esta página de inicio de Notion, por ejemplo, dividir esa página en secciones, como un encabezado, un bloque de héroe, más secciones, algunas más abajo, y envolver cada una de las secciones con suspense, lo que básicamente haría el corte así. Y entonces lo que sucedería ahora sería básicamente lo siguiente. Llamarías a hydrate root. Rect comenzará a renderizar los componentes uno por uno hasta que en algún momento se tropiece con el límite de suspense, que marca la hidratación no bloqueante, y cuando rect se tropiece con este límite, no procedería más allá de ese límite todavía. Seguiría renderizando los componentes argent restantes hasta que termine, y luego finalmente renderizará los no argent devolviendo el control al navegador cada cinco milisegundos. Entonces, si envuelves cada sección de la página con start-transition, lo que sucedería es que cada sección de la página se hidrataría de manera no concurrente devolviendo el control, lo siento, de manera concurrente devolviendo el control al navegador cada cinco milisegundos. Justo como usamos transition. Ahora podrías preguntar, okay, si esto es tan bueno, si esto hace que la página se hidrate de manera no bloqueante, ¿por qué necesito molestar con secciones? ¿Por qué no envuelvo toda la página con suspense? Y la respuesta es que, en realidad, arruinaría tu INP. ¿Por qué? Esto tiene que ver con otro comportamiento de suspense de React18. No tiene realmente un nombre, pero yo lo llamo hidratación argent forzada. El desafío detrás de esto es que en el momento en que haces clic en algún botón de suspense, React lo cambia de nuevo a hidratación argent, por lo que si envuelves toda la página con suspense, se hidratará así, 5 milisegundos a la vez, pero si haces clic en ella justo cuando se está hidratando, React cambiará a la hidratación argent para toda la página, lo que significa que el próximo pintado no sucederá hasta que toda la página esté hidratada, mientras que si solo envuelves secciones separadas de la página con suspense, lo que te dará un renderizado que se ve así, y luego haces clic en algún límite de suspense, entonces solo ese límite de suspense se hidratará de manera argent, lo que tomará mucho menos tiempo y hará que el primer renderizado después del clic ocurra mucho antes y hará que tu interacción para expandir sea mucho más corta. Entonces, por eso no quieres envolver toda la página con suspense. Muy bien, entonces estas son las dos grandes características concurrentes de React. Así es como funcionan y así es como ayudan con el INP. Tómalas, toma tu INP y haz que tu INP sea verde. Gracias. Gracias por las preguntas. La primera dice, ¿hay alguna razón para no envolver la mayoría de las actualizaciones de estado en start transition? Esa es en realidad una gran pregunta. Espera,

Optimiza y sé eficiente.

Sí. Muchas gracias, Ivan. Gracias. ¿Podemos darle a Ivan, que tiene hambre, un aplauso por su increíble charla y por tomar las preguntas? Gracias.