Video Summary and Transcription
La charla discute la métrica NextPaint, una nueva métrica de rendimiento introducida por Google que mide la velocidad de los clics o la entrada del teclado en una página. Explora cómo el renderizado de React puede impactar la métrica NextPaint y ofrece técnicas de optimización como el uso del hook useTransition en React 18. La charla también cubre los cambios introducidos en el proceso de renderizado de React 18, el impacto de envolver con suspense, y la sustitución de la métrica de Retraso de la Primera Entrada con la interacción hasta la próxima página. También se discuten las limitaciones de useTransition y las estrategias generales de optimización del rendimiento de React.
1. Introducción a la métrica NextPaint
Comencemos con dos malas noticias. Primero, no hay componentes de Rack Server en esta charla. Segundo, la interacción con la métrica NextPaint es una nueva métrica de rendimiento introducida por Google. Mide la rapidez de los clics o la entrada de teclado en la página. Esta métrica se convierte en un vital central en marzo de 2024. Profundicemos en la teoría cubriendo la interacción, la interacción con NextPaint y la interacción con NextPaint para la página. En una aplicación React, la interacción de filtrado de notas es lenta, lo que hace que el spinner se congele durante un segundo.
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
2. Entendiendo la Interacción a NextPaint
No sé cómo esta interacción afecta a NextPaint. Para entenderlo, instalo la extensión Web Vitals de la Chrome Web Store. Al habilitar el registro de la consola, puedo ver la duración de cada interacción en la página. La interacción más lenta se convierte en la métrica NextPaint, que puede causar problemas en el futuro. Google deriva esta métrica recopilando valores INP de los sitios web.
esto es lo que hace que la interacción a NextPaint sea mala. Ahora, puedo sentir que esta interacción es lenta, pero no sé cuán lenta es realmente esta interacción. No sé, no sé cuán realmente afecta a la interacción a NextPaint. No sé nada sobre la interacción a NextPaint, ¿verdad? Entonces, una cosa que realmente me gusta hacer para ver cuán rápidas son las interacciones y para ver cómo afectan a esta nueva métrica que Google ha introducido es que me gusta ir a la Chrome Web Store, instalar la extensión Web Vitals. Volver a la aplicación con el papel rojo. Estoy corriendo. Abrir extensiones. Oh, wow. No puedo ver desde aquí. Oh, sí. Puedo ver. Espera. Necesito abrir el conjunto de Web Vitals. Permíteme hacerlo de manera diferente. Sí, no puedo ver dónde está el segundo. Entonces, sí, esto es mejor. Entonces, necesito abrir la configuración de la extensión. Necesito habilitar el registro de la consola. Guardar configuraciones y luego abrir la consola.
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
3. Entendiendo INP y el Renderizado de React
El INP para la página se determina midiendo el 25% más lento de las interacciones y visitas. En las aplicaciones de React, la escritura lenta en el filtro es causada por React renderizando todos los componentes uno por uno, lo que resulta en una entrada lenta. Este renderizado lento afecta la interacción, la experiencia del usuario y el MP. Para optimizar esto, puedes intentar envolver los componentes con la memoria de React, optimizar el componente, virtualizar la lista, hacer uso de debounce y throttle, y utilizar useTransition en React 18 para hacer que las actualizaciones no sean urgentes.
sitio web. Para esa visita, toma todas estas visitas, las ordena, elige el 25% más lento de esas visitas y nombra al más rápido de este lento 25% de visitas como el INP para la página. Entonces, una vez más, lo que es INP, mides cada interacción, eliges el 25% más lento de interacción, luego recoges todas las visitas lentas, eliges el 25% más lento de todas las visitas, y obtienes el INP para la página. Y este INP para la página es amarillo o rojo en casi todas las aplicaciones de React que he visto. Entonces, bien, ahora, volvamos a nuestra aplicación. Nuestra aplicación es lenta, y esto hace que el INP también sea lento. Y si tuviera que debug este problema, vería que este problema, esta escritura lenta en el filtro es causada por el renderizado de React. Aquí está lo que está sucediendo en la aplicación. Entonces, cuando escribo en la entrada del filtro, lo que sucede en la aplicación es que React llama a esta función set filter que es un hook useState. Eso cambia el estado en un montón de componentes, y eso hace que React renderice todos estos componentes uno por uno hasta que termina. Y esto es lo que hace que mi entrada sea lenta. Este re-renderizado es una operación de detener el mundo. Nada puede suceder hasta que React termine. Entonces, cuando escribo en el teclado, la página no se actualizará hasta que React haya terminado de procesar todos los componentes, ¿verdad? Si toma dos segundos procesar todos los componentes, entonces la página no se actualizará hasta dos segundos después. Este es el clásico renderizado lento de React, y esto es lo que hace que la interacción se expanda en las aplicaciones de React. Ahora, tenemos un problema de performance, ¿verdad? Escribo en la entrada del filtro, la aplicación se congela por un segundo. Esto empeora la interacción, empeora la user experience y empeora el MP. Ahora, si fueras mi pregunta para ustedes, si fueras un desarrollador de esta aplicación, ¿cómo intentarías optimizar esto? ¿Cómo intentarías hacer esto más rápido? Spoilers. ¿Alguna otra idea? ¿Debounce? ¿Qué? Sí, bien, entonces, sí, hay un montón de cosas que podrías hacer. Podrías intentar envolver algunas cosas con la memoria de React, si hay algunos componentes que se están renderizando innecesariamente. Podrías optimizar el componente. Podrías virtualizar la lista, si es una lista grande, y es una lista grande. Podrías hacer uso de debounce y throttle. Y una cosa más que podrías hacer, que React está introduciendo, podrías también hacer que las actualizaciones no sean urgentes utilizando useTransition. ¿Qué significa esto? Entonces, con React 17 y versiones anteriores, cada actualización que ocurre en la aplicación se considera urgente. Si haces clic en un botón, React tiene que manejar la actualización inmediatamente. Si escribes en el campo de texto, React tiene que renderizar la lista de nodos inmediatamente, y eso es una operación de detener el mundo. Con React 18, sin embargo, tus actualizaciones ahora pueden tener una prioridad. Cada actualización que haces en la aplicación sigue siendo por defecto urgente, pero lo que React ahora también soporta son actualizaciones no urgentes, y las actualizaciones no urgentes automáticamente no bloquean la página, no importa cuánto tiempo tomen. Vamos
4. Optimizando las Actualizaciones del Estado de React
Tengo el hook useState que controla el estado del filtro. Cada vez que escribo en esta entrada de filtro, el hook useState se actualiza y eso hace que React renderice toda la lista de nodos y haga una interacción realmente lenta. React 18 nos permite tomar una parte del estado y decirle a React que esta actualización no es urgente, utilizando el hook useTransition. Para aplicar useTransition, voy a dividir el único bit de estado llamado filtro en dos bits de estado: filterInput y filterValue. Necesito hacer que controlen los componentes de la interfaz de usuario que me importan y establecer ambos estados al escribir en el filtro. Al usar el hook useTransition, puedo actualizar el bit de estado que controla la lista de nodos de forma no urgente, mientras que la entrada del filtro se actualiza de forma urgente.
veamos cómo funciona esto. Así que, aquí está el código para mi barra lateral izquierda en la aplicación. Hay algunos bits críticos aquí. Tengo el hook useState que controla el estado del filtro. Tengo la entrada del filtro, que renderiza esta entrada. Tengo la lista de nodos, que renderiza estos nodos. Y ahora mismo, cada vez que escribo en esta entrada de filtro, el hook useState se actualiza y eso hace que React renderice toda la lista de nodos y haga una interacción realmente lenta.
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.
5. Optimizando la Renderización de React con useTransition
Para hacer que la entrada del filtro sea más receptiva y prevenir la congelación, envolví el setFilterValue setState con startTransition. Esto permite que la página permanezca completamente receptiva mientras se ejecuta el renderizado costoso. ¡Es como magia! React devuelve el control al navegador después de cada fotograma, utilizando un mecanismo diferente al de request animation frame o request callback. El hook useTransition funciona gestionando una cola de actualizaciones, priorizando los componentes que no necesitan actualizaciones urgentes.
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
6. Entendiendo el Proceso de Renderizado de React 18
React 18 introdujo dos cambios críticos en la función perform work until deadline. Añadió una verificación llamada should yield to host, que determina si React debe devolver el control al navegador. Después del bucle, React verifica si hay actualizaciones pendientes sin procesar y programa otra función perform work until deadline. La función que decide si React debe devolver el control al navegador devuelve true si el renderizado actual ha tardado más de cinco milisegundos. La función que programa los próximos cinco milisegundos de actividad de JavaScript utiliza set timeout 0 u otros métodos compatibles. Esta implementación permite el renderizado no bloqueante de actualizaciones no urgentes, lo que resulta en interacciones más rápidas y repintados de página.
que no necesitan ser actualizadas urgentemente. Son listas de notas y un montón de botones de notas. React también tiene una función llamada perform work until deadline. Esta función toma la cola de actualizaciones y la procesa una por una y en Rect 17, esto era prácticamente todo. Empezarías procesando la cola y seguirías procesándola hasta que terminaras. Y si esto lleva dos segundos, si necesitas renderizar 2000 componentes entonces esto llevaría dos segundos y renderizarías 2000 componentes. Todo este tiempo la página estaría bloqueada. Ahora lo que hizo Rect 18 es que Rect 18 añadió dos cambios críticos. Primero, en el bucle while, añadió una verificación llamada should yield to host, que le dice a Rect si debe devolver el control al navegador. Y segundo, después del bucle, Rect ahora verifica si todavía hay alguna actualización pendiente sin procesar y programa otra función perform work until deadline para ser ejecutada en el próximo fotograma.
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
7. Renderizado Concurrente de React y Suspense para Hidratación
El renderizado no urgente no va a tardar más de cinco milisegundos, manteniendo la métrica de interacción a nextPaint baja. React 18 permite la hidratación concurrente dividiendo la página en secciones y envolviendo cada sección con suspense. Esta hidratación no bloqueante mejora el rendimiento al renderizar los componentes restantes después de que se hayan completado los urgentes, devolviendo el control al navegador cada cinco milisegundos. Envolver toda la página con suspense puede causar una hidratación forzada urgente, impactando negativamente en el INP.
otro botón durante la interacción no urgente... Lo no urgente... Lo siento. Durante el renderizado no urgente... El renderizado no urgente no va a tardar más de cinco milisegundos. Así que, el manejador de eventos onClick y la próxima pintura también van a suceder en no más de cinco milisegundos, lo que mantiene la métrica de interacción a nextPaint baja. Este es el mecanismo de renderizado concurrente de React y así es como mejora la interacción a nextPaint.
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
8. Entendiendo el Impacto de Envolver con Suspense
Si envuelves secciones separadas de la página con suspense, solo ese límite de suspense se hidratará de manera urgente, haciendo que la próxima pintura ocurra antes. Por eso no quieres envolver toda la página con suspense. Los malos números de INP en Google pueden impactar negativamente en el SEO y la experiencia del usuario. El número que ves en las perspectivas de velocidad de la página refleja lo lento que se siente para los usuarios. Google está añadiendo esta métrica ahora porque la han diseñado correctamente, a diferencia de su predecesora, el primer retraso de entrada.
página. Así que harías clic en la página y la página se quedaría congelada. Funcionaría básicamente como si no tuvieras ningún suspense en absoluto. Lo que significa que el próximo punto no ocurrirá hasta que esa hidratación urgente esté completa. Mientras que si 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 urgente. Y eso será mucho más rápido. Y eso hará que la próxima pintura ocurra mucho antes también. Así que por eso no quieres envolver la página entera con suspense. Bien, así que esto es interacción a nextPaint. Estas son las dos características correctas que ayudan con la interacción a nextPaint. Así es como funcionan. Y así es como ayudan. Así que tómalas, toma tu INP y haz que tu INP sea verde. Gracias. Eso siempre es algo bueno. Quizás empecemos con este. No miremos el lado del usuario de las cosas. ¿Qué tan malo es un mal número en Google para mí? ¿Realmente necesito preocuparme como desarrollador? Bueno, en primer lugar, importa si te importa el SEO, va a ser realmente malo para tu SEO. Si no te importa el SEO, creo que no hay un gran incentivo empresarial. Todavía va a ser... Lo siento, puedes creerme después. Va a ser malo para tus usuarios. Y si te importan tus usuarios, eso es algo de lo que aún debes preocuparte. Porque el número que ves en las perspectivas de velocidad de la página, eso es lo lento que es en realidad para tus usuarios. No es solo un número falso medido en algún navegador falso, es cómo se siente en realidad para tus usuarios. Pero aparte de eso, es principalmente SEO y ranking de búsqueda. Vale. Sí. Gracias por eso. Y centrémonos en por qué Google está añadiendo esto ahora. Bueno, ¿por qué no lo añadieron antes? Porque no lo sabían
9. Reemplazando el Primer Retraso de Entrada
El primer retraso de entrada será reemplazado por la interacción a la siguiente página. Los intereses comerciales de Google se alinean con hacer la web más rápida. Quieren motivar a las personas a priorizar la web como una buena experiencia de usuario. Esta métrica ayuda a lograr ese objetivo.
cómo design correctamente. Hay un predecesor de esta métrica llamado primer retraso de entrada. Probablemente no lo notaste porque es verde prácticamente en todas partes. Y ese es el problema, porque si es verde en todas partes, no te muestra nada. Así que el primer retraso de entrada va a ser reemplazado con la interacción a la siguiente página. ¿Por qué no lo añadieron después? ¿Por qué ahora? ¿Por qué no más tarde? Bueno, porque están tratando de hacer la web más rápida. Sé que está en sus intereses comerciales. Y si está en sus intereses comerciales, ¿hay otros intereses que podrían alinearse mejor con otras métricas? Oh, lo siento. No entiendo la pregunta. No, solo me pregunto. Quiero decir, están en el negocio de vender anuncios. Así que hay una razón específica para elegir específicamente esa métrica, mientras que en comparación con otro negocio, podrías preocuparte más por otras métricas. Entonces, mi entendimiento es que básicamente Google se beneficia donde la web es rápida, ¿verdad?, para las personas que eligen la web o las mobile apps. Y para hacer de la web una buena user experience, necesitan, bueno, motivar a las personas para que hagan de la web una buena user experience. Y esta es una de las
10. Limitaciones de useTransition
UseTransition no es efectivo al tratar con un solo componente que tarda mucho tiempo en renderizarse. No puede dividir el componente en fragmentos, lo que hace que la renderización se complete antes de devolver el control al navegador.
métricas que motivan a las personas. Hablando de otra métrica, ¿existen casos que son malos para la interacción con el siguiente panel, que no se pueden solucionar con useTransition? Sí. Así que una de las — esto es en realidad también otra cosa que no encajó — una de las cosas donde useTransition no ayudaría es cuando tienes un solo componente que es muy costoso. Entonces, useTransition divide el trabajo y el borde de los componentes, ¿verdad? Si tienes muchos componentes baratos, que es la mayoría de los casos, eso va a funcionar bien. Pero si tienes un solo componente que tarda 500 milisegundos en renderizarse, useTransition no sería capaz de dividir ese componente en fragmentos. Empezaría a renderizar el componente, y solo después de que esa renderización se complete, sería capaz de devolver
11. Optimización del Rendimiento de React
Los desarrolladores en React 16 todavía pueden optimizar el rendimiento mediante el uso de debouncing, throttling y virtualización. El enfoque en el rendimiento depende de la etapa de la empresa, con las startups priorizando la supervivencia y luego el rendimiento. Las grandes empresas con un ajuste de mercado de productos deben apuntar a capturar usuarios adicionales a través de un mejor rendimiento. La regla 80-20 para el rendimiento incluye el uso de herramientas como Next.js, CDNs como Cloudflare y la monitorización básica del rendimiento. La implementación de estas estrategias puede mejorar significativamente el rendimiento.
el control de vuelta al navegador. Así que ese es un gran caso en el que no ayuda. Sobre los casos que no están ayudando, ¿qué pueden hacer nuestros desarrolladores si todavía están en React 16? Sí, no lo sé. Pero, quiero decir, la lista de optimizaciones que tocamos brevemente, está lejos de ser completa, ¿verdad? Pero definitivamente hay muchas cosas que podrías hacer en React 16 y 17. Es solo que es más difícil, y necesitas perfilar más y pensar más en ello. Es debouncing, throttling, lo sé. Virtualización.
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.
12. Métricas Favoritas y Anidación de Renderizados No Urgentes
¿Cuáles son tus otras métricas favoritas? LCP es una métrica frecuentemente mencionada en las aplicaciones de React. Se ve afectada por el tiempo hasta el primer byte y la carga de CSS. Optimizar LCP puede llevar a mejoras significativas. ¿Pueden los renderizados no urgentes anidarse dentro de renderizados no urgentes? No puedo responder ahora mismo, pero es una pregunta interesante para explorar más a fondo.
Por lo tanto, probablemente podemos mejorar mucho el performance simplemente haciendo eso. De acuerdo. ¿Cuáles son tus otras métricas favoritas que podrían surgir en el futuro, de las que deberíamos estar al tanto? ¿Y qué pasa con el tiempo hasta la próxima diapositiva? Sí. Bueno, mis métricas favoritas... Bueno, no lo sé. Podría decirte que mis métricas favoritas son las tres de Google Corovitals. Eso no es realmente cierto. Son las métricas favoritas de Google. Todavía tengo que lidiar con ellas todo el tiempo. Creo que en las aplicaciones de React, lo que surge muy a menudo también es LCP, Large Discountful Paint. Está parcialmente afectado por el tiempo hasta el primer byte, pero también está afectado por cómo cargas tu CSS, por ejemplo. ¿Tienes una cascada de solicitudes al servidor? ¿Está tu servidor en el mismo dominio o en un dominio separado? Hay un montón de cosas que entran en juego. Y realmente me gusta optimizar eso, y creo que hay muchas cosas interesantes de las que hablar.
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.
Comments