Prepara tu React, Nuevos Core Web Vitals están Llegando

Muy bien, entonces comencemos la charla con dos malas noticias. La primera es que si viniste a la charla por los componentes de Rack Server, no habrá ningún componente de Rack Server en esta charla. No encajaban. La segunda mala noticia es que nosotros, como desarrolladores de Rack, estamos jodidos. Me prohibirían de otra manera si dijera la palabra. Pero este es el Informe de PageSpeed Insights para newyorktimes.com. Puedes ver que todas estas métricas de performance son verdes excepto la interacción con NextPaint. Este es el Informe de PageSpeed Insights para target.com, un gran e-commerce americano escrito en React al igual que newyorktimes.com. Todas las métricas de PageSpeed Insights son verdes excepto la interacción con NextPaint. Este es el sitio web de Notion. De nuevo, todas estas métricas de feed son verdes excepto la interacción con NextPaint. Esta métrica, interacción con NextPaint, es una nueva métrica de performance introducida por Google. Mide la rapidez de los clics o la entrada de teclado en la página. Y en casi todas las aplicaciones o sitios web de React que he visto hasta ahora, esta métrica es amarilla o roja. Y además, esta métrica se convierte en un vital central en marzo de 2024, lo que significa que en pocos meses, tu CTO, tu navegador, 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 optimizarla? Vi una mano. Vale. Bueno, entonces hagamos una inmersión realmente rápida en la teoría. Y para hablar de teoría, necesitaríamos cubrir tres cosas, la interacción, la interacción con NextPaint y la interacción con NextPaint para la página. Entonces, aquí hay una aplicación React. Es una simple aplicación de toma de notas. Podría tomar notas. Podría, en realidad no puedo ver si estoy escribiendo. Puedo tomar notas. Puedo abrir notas. Puedo crear nuevas notas. Y puedo filtrar notas. Y la interacción de filtrado de notas es lenta. Si miras el spinner que gira en esta esquina, que gira cuando la página está inactiva, que se congela cuando la página también se congela, verías que cada vez que escribo en el filtro, el spinner se congela durante un segundo. Y esta es una interacción lenta, y

Y en el momento en que hago eso, y en el momento en que intento hacer algo en la aplicación, vería que la extensión registra cada interacción que hago en la página. Como cuando hago clic en algo, vería cuánto tiempo tardó ese clic. Cuando escribo algo, vería cuánto tiempo tardó esa escritura. Y cada vez que intento escribir en mi entrada de filtro, vería cuánto tiempo tardó esa acción de filtrado. Vería que cada vez que escribo en la entrada del filtro, mi interacción tarda 700, 600 milisegundos. Y podría ver que a medida que la interacción se vuelve más y más alta, también lo hace el valor de la interacción a un INP explicado. Entonces, lo que la interacción a un explicado básicamente es la nueva métrica de performance que Google introdujo es la interacción más lenta que ocurre en la página durante una sola visita de usuario. Entonces, soy un usuario, voy a una aplicación, hago un montón de interacciones en la aplicación, hago clic en cosas, escribo cosas. Y la pulsación de tecla más lenta, el clic más lento de esto va a convertirse en la interacción a una métrica explicada que Google mide. Eso va a ser amarillo o rojo, y eso va a crear muchos problemas para nosotros en solo unos meses. Entonces, ahora, esta fue la interacción a un explicado solo para una sola visita, pero lo que Google muestra es la interacción a un explicado para toda la página. Entonces, ¿cómo deriva Google este número? La forma en que funciona es que si optaste por compartir data con Google, lo que Google realmente hace es que cada vez que vas a cualquier sitio web y haces clic en el sitio web, Google recopila cada valor INP de ese

Entonces, lo que React 18 nos permite hacer ahora, es que React 18 nos permite tomar una parte del estado y decirle a React que, oye, esta actualización no es urgente. Y la forma de hacerlo es utilizando el hook useTransition. Así que, hagamos justamente eso. Para aplicar useTransition aquí, voy a hacer varios cambios. Por favor, tengan paciencia conmigo. El primer cambio que voy a hacer es tomar mi único bit de estado llamado filtro, y voy a dividirlo en dos bits de estado. Los voy a llamar filterInput y filterValue. El primero va a controlar mi componente de entrada. El segundo va a controlar mi lista de nodos. Este se va a llamar setFilterInput y setFilterValue. Ahora, necesito tomar estos dos nuevos bits de estado y necesito hacer que realmente controlen los bits de la interfaz de usuario que me importan. Hecho. Y ahora necesito establecer ambos estados cada vez que realmente escribo en el filtro, ¿verdad? Así que, voy a hacer esto. Perfecto. Hasta ahora, lo que esto haría es realmente no haría nada. Simplemente tomé un bit de estado y lo dividí en dos bits de estado y eso no tiene sentido, ¿verdad? Todavía escribiría en la aplicación, la aplicación sería lenta, y ahora por alguna razón tengo dos bits de estado que almacenan lo mismo. Sin embargo, lo que puedo hacer ahora con reg.tint es que puedo tomar uno de estos bits de estado y puedo decirle a reg.tint que, oye, cuando actualices este bit de estado, el bit de estado que controla la lista de nodos, por favor, actualiza el bit de estado de forma no urgente, porque no me importa si esa actualización se completa. Lo que me importa es que la entrada del filtro se actualice de forma urgente porque ahí es donde el usuario escribe y ahí es donde el usuario debería ver la entrada de inmediato. Lo que no me importa es si la lista de nodos tarda más en actualizarse porque el usuario puede esperar. Y hago eso utilizando el hook useTransition. Así que, hagamos justamente eso. Para usar, para decir, para decirle a la actualización que la actualización del hook set filter value es no urgente, necesito hacer lo siguiente. Necesito importar useTransition. Necesito llamar a useTransition dentro del cuerpo del componente. Necesito obtener el valor isPendingValue y la función startTransition del hook useTransition.

Y necesito envolver mi setFilterValue setState con startTransition. Oh, sí. Trans-ti-ti-tion. Vale. Oh, por eso no lo hizo. Vale. Por eso usas useLint. Entonces, bien. Entonces, el cambio que acabo de hacer es el único cambio que acabo de hacer es que tomé mi función setState y la envolví con startTransition, ¿verdad? Y si lo quito, si lo quito, si simplemente escribo en el filtro, verías que el filtro sigue siendo, escribir en el filtro sigue siendo lento, ¿verdad? Escribo en el filtro y congela la página por un segundo porque Rect tiene que renderizar todos estos componentes y eso lleva mucho tiempo. Ahora, si envuelvo este setFilterState, lo siento, setFilterValue con startTransition, lo que pasaría es que escribiría en la entrada del filtro y la página ya no se congelaría. Escribo en la entrada del filtro y la página es completamente receptiva. Podrías ver que estoy escribiendo y el spinner está girando y estoy escribiendo más en la lista de nodos que se renderiza y en realidad, si el renderizado se envía, se renderiza de inmediato. Podrías ver que no hay retraso como con el rebote o con el estrangulamiento. Maneja la entrada de inmediato. Si el renderizado es más barato, si el renderizado es costoso, simplemente ejecuta el renderizado de forma no urgente. Así que esto es realmente, realmente genial y la página se mantiene completamente receptiva mientras se ejecuta el renderizado costoso. Esto es casi como magia. Ahora, ¿alguien tiene alguna idea de cómo funciona esto? Casi. No. ¿Alguna otra idea? En realidad, no. Pero, sí, estás pensando en la dirección correcta. Así es como funciona esto, lo siento, diapositiva equivocada. Así es como funciona esto, devolviendo el control. Así que Rect comienza a renderizar la aplicación y luego devuelve el control al navegador después de cada fotograma. No utiliza el request animation frame. No utiliza request callback. Utiliza un mecanismo ligeramente diferente y vamos a ver exactamente cómo se ve esto, qué mecanismo exactamente utiliza. Así que bajo el capó, aquí está cómo funciona use transition. React tiene una cola de actualizaciones. En nuestro caso, esta cola tiene componentes

Ahora, should yield to host, la función que decide si Rect debe devolver el control al navegador es en realidad una línea. Simplemente devuelve true si el renderizado actual ha llevado más de cinco milisegundos. Y schedule perform work until the deadline function, la función que programa los próximos cinco milisegundos de actividad de JavaScript, también es bastante simple. No utiliza request animation frame, porque eso no se ejecutaría con suficiente frecuencia. No utiliza request que lo llamará porque tiene un retraso mínimo de 50 milisegundos, creo. Pero simplemente llama a set timeout 0 para programar la próxima llamada perform work until the deadline. O si set immediate o message channel están soportados, los utiliza en su lugar para el mismo propósito. Y eso es prácticamente todo. Así es como está implementado. Si recuerdas la diapositiva del pasado, así es como se comportaba Rect 17 cuando intenté escribir en el campo de filtro. Escribí en el campo que cambió el estado en un montón de componentes y Rect renderizó todos los componentes en un solo paso, congelando la página todo el tiempo. Ahora, con Rect 17, esto cambia. Cuando intento escribir en el campo de filtro, Rect llama a set filter input y luego, inmediatamente después, llama a set filter value. Esto provoca que el estado se actualice en un montón de componentes. Pero ahora, algunas de estas actualizaciones de estado se marcan como urgentes, mientras que otras se marcan como no urgentes. Lo que ahora hace Rect es que todavía renderiza las actualizaciones urgentes de la antigua manera bloqueante, pero luego comienza a renderizar las actualizaciones no urgentes de una manera no bloqueante, devolviendo el control al navegador cada cinco milisegundos. Y como el navegador recupera el control, puede repintar la página mucho antes. La primera interacción va a ser más rápida porque no estamos bloqueados por todos los componentes no urgentes. Y las interacciones subsiguientes también van a ser más rápidas. Así que, por ejemplo, si el usuario hace clic en un botón de nuevo durante... Si el usuario hace clic en algún

Ahora, de lo que hemos hablado hasta ahora era solo una característica que ayuda con el INP, su uso de transición. También hay otra característica concurrente que también ayuda con el INP, y es suspense para la hidratación de React. Así que, si no estás familiarizado con la hidratación de React, es un proceso donde tú renderizas un sitio en el servidor, luego en el cliente hidratas ese sitio, renderizando cada componente de nuevo, adjuntando oyentes de eventos al DOM ya existente, y obtienes un sitio en vivo. Y la hidratación, en mi experiencia, es típicamente la operación de JavaScript más costosa que una aplicación de React podría tener. Como, por ejemplo, aquí está Deliveroo gastando 1.55 milisegundos hidratando el sitio con un estrangulamiento de 4xvelocidad. O aquí está Notion gastando 1.8 segundos, o aquí está Walmart gastando 1.1 segundos. Y no quiero decir que estos sitios web o estos equipos sean malos. Esta es una situación estándar, porque la hidratación tiene que renderizar cada componente único en la página y porque lo hace de esta manera estándar de bloqueo, eso mantiene la página congelada durante un tiempo realmente largo. Ahora, lo que React 18 te permite hacer es te permite tomar tu sitio e hidratarlo de manera concurrente. Para hacer esto, necesitas tomar tu página, como, por ejemplo, esta página de aterrizaje de Notion, dividir esa página en secciones, como un encabezado, un bloque de héroe, más secciones, algunas están más abajo, y envolver cada una de estas secciones con suspense, que básicamente se vería así en el código. Ni siquiera necesitas especificar el bloque completo. Solo la etiqueta de suspense. Y lo que sucedería ahora sería básicamente lo siguiente. Llamarías a hydrate root, React 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 React se tropiece con este límite, no procederá más allá de ese límite todavía. Seguirá renderizando los componentes argentinos restantes hasta que termine. Y entonces, solo entonces, una vez que haya terminado, renderizará los no argentinos, devolviendo el control al navegador cada cinco milisegundos. Justo como con useTransition. Y esto es lo que ayuda mucho al INP. Ahora, podrías preguntar, vale, si esto es tan bueno, si esto hace que la página se hidrate de manera no bloqueante, ¿por qué necesito molestarme dividiendo la página en 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 React 18, al que llamo hidratación forzada urgente. No hay un nombre oficial, solo mi nombre. El desafío detrás de esto es el momento en que haces clic en algún límite de suspense que tienes en tu aplicación durante la hidratación, React cambia ese límite de suspense a hidratación urgente. Así que si envuelves toda tu página con suspense, se hidratará así cinco milisegundos a la vez, ¿verdad? Pero entonces, si haces clic en la página justo durante, justo cuando se está hidratando, lo que sucedería es que React cambiará a la hidratación urgente para la parte restante de la

Relacionado con eso, ¿cuánto deberíamos centrarnos en performance mientras desarrollamos cosas, o deberíamos solo echarle un vistazo cuando notamos problemas específicos de performance? Oh, como consultor de performance, voy a decir, no, en realidad, no tengo una buena respuesta para esto, ¿verdad? Mi opinión actual, con la que estoy muy contento de que se discrepe, mi opinión actual es que si estás en una startup, entonces tu primer objetivo es sobrevivir. Tu segundo objetivo es performance. Enfócate en las características, enfócate en el ajuste de mercado del producto. Luego, si encuentras el ajuste de mercado del producto, enfócate en retener a los nuevos usuarios y mantener un buen performance. Si estás en una gran empresa, entonces, bueno, si ya tienes el ajuste de mercado del producto, entonces supongo que estás interesado en capturar el sobrevivir-tomar el 10, 20% de los usuarios que van a venir a ti si tienes un mejor performance. Así que en ese punto, importa mucho más que al principio. ¿Y cuáles son tus reglas 20, 80 para performance? Si alguien quiere enfocarse en los usuarios, pero tiene un poco de presupuesto de tiempo? Wow, está bien, no estaba preparado para responder a eso. Pero bueno, no lo sé. Toma Next.js. Sé que algunas personas se van a quejar de Next.js más tarde en este escenario, pero Next.js sigue siendo lo suficientemente bueno. Toma algún CDN como Cloudflare, pon en marcha alguna monitorización básica de performance, como si fueras centrado en el centro y haces alguna monitorización básica de performance, como hacer estas tres cosas, eso va a ser 80-20. Y sí, podrías tomarlo desde allí más tarde. Chequeo rápido con la audiencia, ¿quién ya está haciendo todo eso? Veo tres manos.

Pero mientras hablamos de optimización, quizás una última pregunta. ¿Puedes realmente renderizar los renderizados no urgentes dentro de renderizados no urgentes en algunos casos? ¿Perdón, puedes repetirlo? Nidos, sitio de renderizado urgente, no, do, do, do, do, do, do. Buena pregunta. No puedo, sí, no puedo responder ahora mismo. Lo siento. Mi modelo mental es... Necesito dos minutos para pensar sobre eso. No pude responder a esto. Quiero decir, creo que es genial porque necesitamos cerrarlo de todos modos. Pero puedes seguir con eso en la sala de discusión. Gracias. Muchas gracias por estar aquí, haciendo buenas preguntas.