Visualización de Cuellos de Botella de Rendimiento Front-End

¿Cómo estás aprendiendo React por tu cuenta? Las herramientas basadas en web de React te permiten diseñar y aprender por tu cuenta. Estas herramientas solo están disponibles para usuarios que trabajan en su propio proyecto. Si estás buscando una forma de aprender más sobre los lenguajes y enseñanzas de React, hay muchos recursos disponibles en el sitio web de Flutter.

Ahora le cederé la palabra a Rich para que te muestre cómo hacerlo por tu cuenta.

Hola. Antes de comenzar, me gustaría agradecer a los organizadores y a los demás oradores de React Summit. Hasta ahora ha sido una conferencia realmente genial y todos están haciendo un gran trabajo. Hoy hablaré sobre el rendimiento web. Mi nombre es Rich. En GitHub y Twitter me conocen como Richie McColt. Soy un ingeniero de front-end y trabajo en una empresa llamada Dazzone en Londres. Soy originario de Glasgow, Escocia. Probablemente puedas notarlo por el acento. Antes de comenzar a hablar sobre el rendimiento web, daré una breve introducción sobre lo que hacemos en Dazzone. Dazzone es un servicio de transmisión de deportes en vivo y a pedido. Estamos presentes en nueve mercados de todo el mundo y brindamos acceso a millones de clientes para que puedan ver los deportes que desean. El equipo en el que trabajo es responsable de los dispositivos de sala de estar. Los dispositivos de sala de estar se dividen en tres categorías: televisores inteligentes, como Samsung, Toshiba y Panasonic; consolas de juegos, como PS4, PS5 y Xbox; y decodificadores, como Comcast, Fire TV y Sky Q. Para poner el rendimiento en contexto con lo que hacemos en Dazzone, los problemas con los que nos enfrentamos están relacionados con objetivos de memoria y CPU bajos, competencia de recursos en el hilo principal. Por ejemplo, si hay una reproducción en segundo plano y el usuario intenta navegar por el contenido al mismo tiempo, debemos mantener interacciones fluidas a 60 fps cuando los clientes navegan por el contenido. Los datos no mienten, ¿verdad? Los sitios web rápidos equivalen a una mejor experiencia de usuario. Esto es lo que prefieren los clientes y es algo a lo que debemos aspirar. Este documento técnico de Cloudflare Getting Faster demuestra algunas citas útiles. Las conversiones disminuyen un 7% debido a solo un segundo adicional de tiempo de carga. Y el 39% de los usuarios dejan de interactuar con un sitio web si las imágenes tardan demasiado en cargarse.

Y otra gran cita del ensayo de Craig Maud sobre software rápido es que, para mí, el software rápido marca la diferencia entre una aplicación integrada sin problemas en tu vida y una a la que se llama con gran renuencia. Y como usuarios de software, definitivamente podemos relacionarnos con esto en algún momento u otro.

Entonces, hoy, lo que cubriremos es comprender el método de medición, análisis y solución. Toquemos brevemente el tiempo del usuario y ZPI que proporciona el navegador. Tendremos una demostración en vivo de medición y análisis de una ejecución lenta en código JavaScript. Presentaré la técnica de renderizado de virtualización. Hablaré brevemente sobre los problemas de rendimiento a los que nos enfrentamos en Dazzone. Y finalmente, solucionaré el cuello de botella de rendimiento que tenemos en la demostración.

El ciclo de medición, análisis y solución es una metodología que suelo utilizar al realizar auditorías de rendimiento. Antes de poder analizar y solucionar un problema, primero debemos medir. La medición nos dará la línea de base que necesitamos para analizar el problema realmente. Una vez que analizamos el problema, podemos proponer una solución. Una vez que solucionamos, volvemos a medir. Y este ciclo se repite hasta que obtenemos un nuevo número con el que estamos satisfechos al medir.

Tengo una demostración, una pequeña aplicación de frontend. Está disponible en esta URL de GitHub. Las instrucciones de configuración están en el archivo Léame. Así que si quieres seguir, siéntete libre de hacerlo. Cambiaré a la demostración que tengo en ejecución. Esta aplicación es solo una pequeña aplicación de frontend que utiliza la API de SpaceX para mostrar una lista de lanzamientos de más nuevos a más antiguos. Una interacción que perfilaré es cambiar el orden de los lanzamientos. Entonces, si hago clic en este botón, ahora estoy viendo los lanzamientos más antiguos de SpaceX.

Para perfilar esto, lo que haremos es ir a las Herramientas de desarrollo en Chrome y utilizaremos el panel de Rendimiento. Luego, iremos a la opción de CPU aquí y haremos clic en ralentizar seis veces. Luego, iremos aquí y presionaremos grabar. Y lo que haremos es interactuar con esta función varias veces para obtener algunos datos y detener la grabación. Bien, genial. Lo que podemos ver aquí es que hay bastante actividad. Lo que realmente nos preocupa es esta sección aquí. Esta sección es el hilo principal.

Y para aquellos que no están al tanto de lo que sucede en el hilo principal, pasaré rápidamente a una diapositiva diferente y podemos explicar la teoría detrás de ello. Esta imagen aquí es del artículo de blog de Paul Lewis llamado la anatomía de un fotograma. Y esencialmente, el navegador realiza un conjunto diferente de tareas en cualquier momento dado para mostrar cosas en la pantalla. Entonces, cuando estamos perfilando y vemos algo amarillo, sabemos que se ha ejecutado JavaScript. Cada vez que vemos morado, sabemos que se ha calculado el estilo del diseño. Y cada vez que vemos verde, sabemos que hay alguna pintura o composición en la pantalla.

Entonces, volvamos a esa demostración. Ahora que entendemos un poco sobre lo que significan los colores. Si analizáramos esta interacción. Podemos ver aquí que tenemos un evento de clic. Hay algo de amarillo, lo que significa que se está ejecutando JavaScript. Hay algo de morado, lo que significa que hay estilo. Algo de diseño. Y finalmente, hay un poco de verde, lo que significa que la actualización de la pintura ocurre en la pantalla.

Entonces, saltemos rápidamente a cómo medimos las cosas. Pero antes de hacer eso, quiero tocar rápidamente este tema, que es que siempre queremos medir en comparación con la versión de producción. La razón de esto es que las bibliotecas de desarrollo como React tienen código y construcción de desarrollo que no está en la versión de producción. Lo que significa que el código que los usuarios o clientes podrían estar experimentando no es el mismo que el que estarías utilizando en una construcción de desarrollo. Así que siempre mide las versiones de producción solo para tener una idea real de los números.

Entonces, dicho esto, ¿cómo medimos? Esa es la primera pregunta que debemos responder. Eso me lleva a la API de tiempos de usuario. Y la API de tiempos de usuario es proporcionada por el navegador y podemos acceder a ella a través de la ventana performance, que es un objeto. Hay algunos métodos útiles en la ventana performance, como mark. Y lo que hace mark es crear una marca de tiempo de alta resolución. Y podemos asociar esa marca de tiempo con un nombre. Y luego podemos acceder a estas marcas de tiempo usando window performance measure. Y en este ejemplo, he creado dos marcas de tiempo, una llamada create mark start y la otra create mark end. Luego podemos acceder a ellas más tarde usando window performance measure. Y window performance measure crea una nueva marca de tiempo, pero calcula la duración entre un inicio y un final. Entonces, window performance measure es cómo visualizamos cosas en las herramientas para desarrolladores.

OK, ahora que sabemos un poco sobre los fotogramas, sabemos cómo medir. Saltemos a la demostración y comencemos a intentar crear una línea de base. Lo primero que podríamos hacer es, si pensamos en la interacción que estábamos perfilando, cuando hacemos clic en ese botón, el estado cambia y el orden de las tarjetas se actualiza en la pantalla. Entonces, lo primero que podríamos hacer es crear la primera marca de tiempo, que sería el inicio dentro del evento on-click del botón. Así que saltaré a VS Code aquí y podemos echar un vistazo al código. Esta es la aplicación de demostración localmente.

Tiene el componente de la última lista de lanzamientos, que es el componente funcional que tiene el botón y muestra una lista de lanzamientos. Así que dentro de aquí, dentro del on-click, marquemos el inicio. Eso es lo primero que tenemos que hacer. Para marcar el final, tenemos que usar un código de instrumentación. Y este código de instrumentación es solo un gancho personalizado que usaremos para almacenar el valor de la renderización anterior dentro de la referencia. Copiaré este gancho personalizado. Y la forma en que lo usaremos es así. Tenemos un efecto que se ejecuta después de la renderización que compara el orden anterior, que hemos utilizado en el gancho personalizado, y lo comparamos con una nueva propiedad de orden. Si esos dos valores son diferentes, sabemos que el estado ha cambiado y podemos marcar el final de esa transición. Así que si copio y pego esto, y lo pongo aquí, eso nos dará algo para analizar y medir en las herramientas para desarrolladores. Ahora volvamos a la demostración. Eso se ha recargado, así que simplemente borraré esta grabación. Presionaré grabar nuevamente y, nuevamente, simplemente interactuaré, cambiaré el orden de los lanzamientos varias veces.

De acuerdo, hay muchas cosas sucediendo aquí. Tomemos este ejemplo. Como puedes ver, en la sección de temporización del usuario, ahora tenemos una nueva medida. Esta es la medida que acabamos de agregar para comprender la línea de base. Armados con la teoría que teníamos para los frames, podemos ver que esta combinación de diseño y pintura de estilo JavaScript es aproximadamente de 634 milisegundos para esa interacción. Además, recuerda que agregamos el código de instrumentación. Queremos restar el código de instrumentación de ese número. Entonces, esto aquí será ese código de instrumentación, alrededor de 58 milisegundos. Entonces, si restamos 58 de 634, estamos aproximadamente en 500 a 550 milisegundos. Esa es la línea de base con la que estamos trabajando.

Entonces, si pensamos en lo que sucede durante esa interacción, estamos cambiando el orden de las tarjetas, ¿verdad? Entonces, la pregunta es, ¿cuántas tarjetas o lanzamientos tenemos en el DOM? Una forma rápida de hacer esto sería cambiar a la pestaña Elementos y buscar el elemento contenedor. Entonces, si miramos este elemento aquí, tiene la lista de lanzamientos. Si hago clic en esos tres puntos y lo guardo como una variable global, significa que ahora puedo acceder a ese elemento y puedo leer algunas propiedades en él. Por ejemplo, la cantidad de elementos secundarios, que me dará la cantidad de lanzamientos que tenemos. Entonces, lo que tenemos aquí son 102 elementos en el DOM. Esto obviamente está generando mucho trabajo para el navegador cada vez que hacemos esa transición.

Entonces, ¿cómo podríamos mitigar esto? ¿Cómo podríamos solucionar este problema? Eso me lleva a la técnica de la virtualización. La virtualización, también conocida como enmarcado, es una forma de renderizar eficientemente una gran lista de contenido. Personalmente, creo que enmarcado es un término mejor para este concepto. Si observamos esta imagen aquí del artículo de desarrollo web, que recomiendo leer, esto ilustra realmente el concepto. El usuario solo está viendo tal vez una cierta cantidad de elementos en la pantalla en un momento dado. Pero también hay algunos elementos fuera de la pantalla que el usuario no ve inicialmente. Por ejemplo, veamos si al usuario le gusta desplazarse rápidamente. Entonces, la ventana cambiaría sobre un subconjunto de esa lista. Y es una forma eficiente de renderizar contenido, como si tuvieras una lista grande.

Antes de aplicar esta técnica en la demostración, haré un pequeño desvío sobre el trabajo que estábamos realizando en la zona. Así que adoptamos la virtualización en la zona. Y antes de adoptarla, estábamos utilizando un enfoque de carga lenta para renderizar el contenido. Y lo que se puede ver en este GIF es que al subir y bajar el contenido, simplemente cambiamos la ventana de lo que el usuario ve en cualquier momento dado. El problema que teníamos antes era que a medida que el usuario interactuaba y subía y bajaba el contenido, estábamos cargando contenido de forma lenta y cambiando el DOM y actualizando nuevos elementos. El problema con eso en dispositivos de baja gama es que realmente causa un retraso significativo y una interrupción significativa en la user experience. Por lo tanto, queríamos eliminar eso para proporcionar una buena user experience en todos estos diferentes dispositivos.

La virtualización realmente ayudó aquí. Este es solo un ejemplo vertical. Aquí está el ejemplo horizontal sin ninguna animación. Como puedes ver, solo hay alrededor de cinco elementos en pantalla horizontalmente en cualquier momento dado. Fuera de la pantalla, hay tal vez dos a cada lado. Si el usuario va rápido, por ejemplo, si tiene un control remoto y mantiene presionada la tecla derecha o izquierda, entonces el renderizado es bastante eficiente porque solo estamos cambiando el subconjunto de la vista.

También vale la pena hablar sobre las limitaciones en la TV y cómo son ligeramente diferentes a las limitaciones que puedes enfrentar en la web móvil. Por ejemplo, en la TV, uno de los grandes problemas es la gestión del enfoque y mantener un enfoque consistente en diferentes páginas. Otro problema es la amplia gama de especificaciones de hardware. Por ejemplo, algunos de estos dispositivos tienen una memoria y CPU muy baja, y otros tienen una memoria y CPU aceptables. También estamos lidiando con una amplia gama de motores de navegadores. Creo que el navegador más antiguo que admitimos es Safari 6, que es bastante antiguo. Y obviamente eso significa que hay una falta de estándares web modernos. Al mismo tiempo, también hay una falta de herramientas para desarrolladores, lo que significa que es realmente complicado navegar por este panorama cuando se trabaja con el rendimiento. Y cuando estamos construyendo esta aplicación front-end en la zona, la escribimos una vez y la ejecutamos en todos estos diferentes dispositivos. Por lo tanto, cualquier técnica que utilicemos, como la virtualización, debe demostrar ser efectiva en todos estos diferentes dispositivos.

Algunos datos antes y después de la virtualización. Tomé este perfil utilizando Fire TV con reproducción y la interacción iba de la parte superior de la pantalla a la parte inferior. Así que estaba presionando en el teclado para subir y bajar solo para llegar al final del contenido. Y lo que pudimos ver al adoptar la virtualización fue una reducción del 34% en la ejecución de JavaScript, una reducción del 43% en estilo y diseño, y una reducción del 59% en pintura. Lo cual es una mejora bastante significativa en términos de experiencia de usuario. Fue mucho menos entrecortado, las interacciones fueron mucho más suaves, y pudimos mantener 60 cuadros por segundo en estas interacciones.

Entonces ahora hemos hablado sobre la virtualización y qué es la técnica, ¿por qué no intentamos aplicar eso a esta demostración, dado que tenemos una gran lista de contenido? La biblioteca que usaré se llama Masonic, y en el ecosistema de React, hay una amplia gama de bibliotecas de virtualización. La razón por la que elegí Masonic para esto es que es realmente simple para comenzar. Tiene una API de renderizado de propiedades y solo le decimos al componente qué ancho queremos, y cambiamos la forma en que renderizamos las tarjetas. Así que copiaré esto. Solo cambiaré la forma en que renderizamos las tarjetas. Así que si muevo esto aquí arriba, guardo eso, y vuelvo a la aplicación de demostración en localhost. Solo cerraré la consola, borraré la grabación, y presionaré grabar y solo interactuaré un poco más con esto.

Y en realidad, lo que noto es que es más rápido. Hay mucho menos interrupciones que antes. Así que detengamos la grabación.

Bien, acerquémonos a esto. Ahora estamos viendo alrededor de 97 milisegundos para esa interacción, lo cual es una mejora drástica desde los 550 milisegundos. Entonces, la aplicación sigue funcionando como se esperaba. Es solo una lista de contenido. La única diferencia es si miramos el DOM y solo inspeccionamos el elemento contenedor, lo que estamos tratando aquí no son 102 lanzamientos. Estamos tratando con 1, 2, 3, 4, 5, 6. Entonces, solo hay algunos elementos en pantalla en un momento dado, pero se renderizan de manera eficiente y los nodos del DOM se mantienen consistentes en cuanto a la cantidad de nodos del DOM.

Bien, eso es una buena mejora. Estoy contento con eso. Lo siguiente que deberíamos hacer antes de terminar es medir la compilación de producción solo para tener una idea de lo que los usuarios pueden experimentar. Entonces, lo que haré es ejecutar el comando de compilación y luego haré npm run serve, que iniciará un localhost en el puerto 5000, creo. Entonces cambiaré aquí, iré al puerto 5000, y cargará la aplicación. Así que borraré esta grabación. Presionaré grabar y seguiré interactuando un poco más con esto. Entonces las imágenes tardaron un poco en cargarse. Pero podemos ver por la interacción que en realidad el DOM se actualiza bastante rápido. Así que podemos perfilar esto aquí. Puedes ver que ahora ha tomado alrededor de 46 milisegundos para hacer esa interacción, lo cual, considerando que estábamos haciendo alrededor de 550 en una compilación de desarrollo, está bien. La virtualización ofreció mejoras significativas en este caso. Hay más mejoras que podríamos hacer. Realmente no tengo más tiempo para profundizar en eso, pero hay otras técnicas que podríamos usar. Entonces hemos medido y analizado, tenemos una línea de base, que es alrededor de 46 milisegundos, y hemos medido la compilación de producción. Entonces, para concluir, realmente hablamos sobre el ciclo de medición, análisis y corrección, cómo podemos usar eso para identificar problemas de performance, tenemos la API de tiempo de usuario, que es solo una forma de medir. Y he presentado la técnica de virtualización, que es extremadamente útil para renderizar grandes listas de contenido. Y eso es todo. Espero que esto haya sido interesante. Espero que hayas aprendido algo.

Si tienes alguna pregunta o comentario, no dudes en contactarme en Twitter y GitHub como Richard McCall. Y espero que disfrutes el resto de la conferencia. Gracias. Mantente seguro. Adiós.

Excelente. Excelente. Muchas gracias por dar esta charla y por estar aquí con nosotros hoy para las preguntas, y veo que algunas personas ya están bastante activas enviando preguntas, así que vamos directo al grano.

Tenemos una pregunta. Tenemos una pregunta de G Halpern, quien pregunta, En tu demostración, usaste performance.mark para definir diferentes marcas de tiempo y luego performance.measure para calcular el tiempo transcurrido. Pero, ¿qué hace performance.measure cuando solo se le da un parámetro, que es el nombre? Bueno, performance.measure necesita un inicio y un fin. Entonces, si solo le das uno, en realidad no estás midiendo nada, ¿verdad? Debes tener algún punto de inicio y final para medir el código. Entonces, si solo le das un final, debes preguntarte, ¿qué estás midiendo? Quiero decir, está bien. Es una pregunta válida.

También tenemos una pregunta de Mike. ¿Cuál es tu opinión con toda la caza de performance en la que invertiste y donde todo tenía absolutamente sentido? Pero, ¿cuál es tu opinión sobre la optimización prematura? Si crees que es un problema, ¿cómo abordarlo? Supongo que hay varios tipos de optimización prematura. Como el caso en el que intentas optimizar código que aún no has medido, que probablemente sea uno de los grandes problemas. Como ya he dicho varias veces en esta charla, se trata de medir y obtener los datos en primer lugar. Una vez que has medido y tienes los datos, entonces puedes comenzar a optimizar cosas. Si sientes que estás optimizando código antes de medirlo, ¿cómo sabes cuáles fueron las mejoras si nunca mediste al principio? Creo que siempre medir es realmente la clave principal.

Lo cual me lleva a una pregunta propia. Veo que has hecho esto muy específicamente en las herramientas para desarrolladores. Pero veo que básicamente hay una API de JavaScript. ¿Cómo monitorearías el rendimiento en tus sitios? ¿Hay herramientas que puedes usar? ¿Existen soluciones prehechas o tienes que hacerlo tú mismo? Sí. Buena pregunta. En performance, las herramientas se dividen en dos categorías principales para mí. Así que tienes herramientas de laboratorio y herramientas ROM. Las herramientas de laboratorio son algo como Lighthouse o React Profiler o DevTools, por ejemplo, que prueban el rendimiento en un entorno muy controlado. Y lo que quiero decir con eso es que puedes cambiar una variable y ver cómo cambia y seguir haciendo eso hasta que tengas algo que pueda funcionar. Ese es el entorno de laboratorio.

Para un entorno ROM, que es como el monitoreo de usuarios reales, hay algunas herramientas que podrías utilizar, ¿verdad? Lo que he mostrado aquí es más o menos la API de performance en la ventana. Pero con eso, tienes que tener cuidado en términos de soporte del navegador. Para nosotros en TV, no es lo mejor dado que soportamos navegadores realmente antiguos y no todos admiten la API de medición de performance. Así que eso es algo de lo que hay que estar consciente. Puedes hacerlo si solo estás soportando navegadores modernos. Pero hay otras herramientas como Speedcurve, que es bastante buena. Esa es una opción de monitoreo ROM realmente robusta. Pero obviamente tiene un costo. Y hay productos similares que hacen cosas similares como New Relic que admite el monitoreo de performance en el front-end. También Sentry hace lo mismo. Así que hay algunas opciones, pero realmente se trata de monitoreo de laboratorio y ROM. Por lo tanto, debes encontrar una estrategia que involucre de manera óptima ambos lados de eso, supongo.

Además, Ojo está preguntando, ¿es posible combinar de alguna manera la virtualización y la amigabilidad con SEO en la página? Quiero reducir el trabajo en el hilo principal, pero Googlebot debería ver todo el contenido en el sitio. Es una muy buena pregunta. Realmente no tengo experiencia con eso y tratando de hacer que funcione con el rastreador de JavaScript de Google. No sé qué tan robusto sería un rastreador de JavaScript para algo como la virtualización. Tal vez alguien allá afuera ya conozca la respuesta a eso. Esa es una buena pregunta. Vale la pena investigarlo. Creo que esa pregunta también podría estar apuntando en mi dirección porque en realidad trabajo en el equipo de relaciones de búsqueda de Google y estoy muy familiarizado con Googlebot y sus capacidades de rastreo de JavaScript. Hay varias formas. Una forma sería renderizar de forma dinámica, lo que significa pre-renderizar o renderizar en el servidor una versión con todo el contenido solo para Googlebot. Eso también es aceptable. Además, si está fuera del hilo principal, deberíamos poder ver al menos parte de él. Verifícalo en las herramientas de testing para ver si estamos viendo tu contenido, y alternativamente, tendrías que encontrar formas de presentar el contenido a Googlebot como renderizado dinámico, renderizado en el servidor, etc. Es posible. Solo requiere un poco de testing para asegurarse de que no haya problemas y sorpresas. Sé que nuestra implementación de trabajador web no es perfecta, pero volviendo a la audiencia, Layard pregunta, ¿alguna sugerencia sobre cómo hacer instrumentación automática? Y creo que ya hemos cubierto esto, pero ¿tienes algo más que quieras decir sobre ese tema también? Bueno, si estás en un entorno de laboratorio y quieres usar la API de rendimiento de la ventana, noté que Lighthouse recientemente comenzó a incluir estas medidas dentro de la propia auditoría.

Entonces, eso es algo que quizás quieras revisar. Recientemente noté que, cuando intentaba ejecutar Lighthouse en un horario diario para algunas de las aplicaciones de TV que tenemos, y estaba accediendo a la página de autenticación que dice registrarse e iniciar sesión, noté que todavía tenían algunos de los pagos de React en nuestro entorno de Edge. Y pensé, eso es extraño. Parece que algunas de estas medidas de rendimiento realmente aparecieron en Lighthouse. Pero también fue así como me di cuenta de que estaban enviando la compilación incorrecta a ese entorno, así que dos problemas sorprendentes.

Eso es genial. Entonces también puedes ejecutar Lighthouse de manera automatizada en un horario. Sí, de hecho, estoy trabajando en una publicación de blog en este momento que configura un informe de Lighthouse sin servidor para que puedas ejecutarlo en un horario y recibir una pequeña notificación que diga, `oye, tu rendimiento es del 98 o algo así`. Lighthouse es realmente bueno. Estoy muy impresionado con Lighthouse en los últimos lanzamientos. Además, tu charla fue muy práctica, y eso es increíble. Pero hay una pregunta de Bri que también me surgió a mí. Yo también tenía esa pregunta. ¿Qué recursos adicionales recomendarías para alguien que está comenzando a analizar y mejorar el rendimiento? Hemos hablado un poco sobre cómo puedes automatizar esto y cómo puedes hacerlo de manera práctica. ¿Qué recursos recomendarías a alguien que recién está comenzando y tratando de entender lo que está viendo?

Sí, supongo que lo primero, antes de intentar solucionar cualquier problema de rendimiento, es obtener los datos en primer lugar. Depende de cómo controles el entorno, pero hay herramientas como pruebas de páginas web que ofrecen la opción de realizar pruebas masivas. Eso sería útil para obtener los datos en primer lugar. Realmente lo que quieres hacer es, una vez que tienes estos puntos clave de datos, comenzar a analizar los datos y desglosar de dónde podrían provenir los problemas, en qué páginas se encuentra el rendimiento, porque realmente lo que quieres hacer es tener un problema de rendimiento en primer lugar. No quieres comenzar a mejorar el rendimiento si no hay ningún problema. Por ejemplo, si estás trabajando en un negocio, debes asegurarte de que este problema de rendimiento esté afectando los resultados finales para el negocio. Debes obtener puntos de datos y luego determinar dónde están los problemas, y luego llevar eso al negocio y decir, `oye, el problema de rendimiento está aquí, propongo que hagamos esto, esto, esto y esto, luego podemos intentar solucionarlo`. Así es como te acercarías a esto desde un punto de vista empresarial. Desde un punto de vista práctico, intenta involucrarte y simplemente entender cómo hacerlo. Hay muchos recursos excelentes, como Google, que probablemente es el mejor lugar para cualquier recurso de rendimiento que he encontrado en mi carrera. Como el Google Summit que hacen, el Chrome Summit. Todas las charlas que hacen una vez al año, siempre hay algo nuevo para ver en esas charlas, así que lo recomendaría. Genial. Además, para evitar problemas de rendimiento desde el principio, Ana pregunta si hay buenos hábitos que recomendarías a alguien nuevo en React para incorporar en su flujo de trabajo y ayudarlos a tener un buen rendimiento a largo plazo y no encontrarse con problemas de rendimiento en primer lugar. Supongo que, desde el punto de vista de React, típicamente estás midiendo el tiempo de carga de la página o las interacciones. Entonces, el tiempo de carga de la página, puedes hacerlo cuando quieras, realmente. Si tu página se carga rápido y no hay nada de qué quejarse.

Si tu página se carga rápido y no hay nada de qué quejarse. En cuanto a trabajar en React y trabajar en rendimiento a medida que avanzas, diría que pienses en las interacciones que estás construyendo y luego intentes comprender qué está sucediendo internamente, creo que es bastante útil. Muchas personas dicen que no deberías tener que mirar internamente, pero en realidad no estoy de acuerdo con eso. Creo que si estás hablando de rendimiento, debes adentrarte un poco más y comprender las interacciones y lo que sucede. Y como dije antes, siempre mide una compilación de producción. Así que no midas como lo hice en la demostración, simplemente midiendo la compilación de desarrollo. Siempre mide la compilación de producción.

Hablando de la compilación de producción, esa es una pregunta interesante de Matthias. ¿Cómo, o realmente miden el rendimiento de sus aplicaciones en los televisores de los clientes también? Quiero decir, ustedes quieren estar en el entorno de producción tanto como sea posible, y eso serían los televisores de los clientes, ¿verdad? ¿Lo hacen?

Sí. No, no lo hacemos, pero es algo en lo que estamos trabajando más, no desde el punto de vista del monitoreo de usuarios reales, sino más bien en un laboratorio. Así que tenemos un laboratorio de dispositivos de prueba con todos estos diferentes dispositivos, y lo que queremos hacer es comenzar a analizar las interacciones en un entorno de laboratorio, pero también es un entorno de dispositivo real. Así que es un enfoque híbrido, pero en producción, no. Porque, como dije, algunos de estos navegadores no admiten algunas de las cosas que intentamos hacer, como el marcado y la medición del rendimiento web moderno. Así que es un poco arriesgado para algunos de estos entornos, dado que se compila una vez y se cierra.

Sí. Suena, sí, un punto válido. Otra pregunta más de Spidey, o Spidern, es que en la demostración hay 100 elementos, ¿no es eso todavía un número muy pequeño de elementos para necesitar virtualización? Siento que estamos resolviendo la mayoría de los errores mediante la virtualización hasta que no sea suficiente. ¿Crees que es una buena práctica?

Bueno, quiero decir, la demostración es solo para ilustrar el concepto, tal vez cien elementos. Depende, ¿verdad? Si estás pensando en un Moto G4, como un teléfono promedio estándar, entonces si tienes cien componentes React en la pantalla en un momento dado, y estás tratando de cambiar el orden de ellos en cualquier momento dado, realmente estás poniendo al navegador bajo mucha presión. Así que la virtualización resuelve esa técnica de tener, digamos, seis elementos en el DOM, lo cual es mucho más estable en términos de CPU y también de memoria. Entonces, quiero decir, lo que realmente quieres hacer es medir. No sabrías si cien elementos son muchos o muy pocos a menos que midas. Y por lo que hemos visto en la demostración, incluso midiendo en una computadora portátil moderna con una desaceleración de seis veces, el navegador estaba pasando por mucho solo para hacer esa actualización y era bastante entrecortado. Así que imagina cómo sería eso en un dispositivo de gama baja. Ya veo. Muy bien. Muchas gracias, Richie. Creo que deberíamos pasar al mentee, Paul, que nos diste y ver qué ha dicho la audiencia allí. Así que echemos un vistazo rápido. De acuerdo. Además, gracias de nuevo. Muchas gracias de nuevo por A, la fantástica charla. Creo que no vemos suficientes charlas sobre rendimiento, para ser honesto, porque el rendimiento sigue siendo un gran problema. Y también, B, por todas las preguntas y respuestas. Sé que ha sido mucho y espero que tengas un día fantástico. Muchas gracias por venir. Perfecto. Gracias, Martin. Disfruten el resto de la conferencia, todos. Adiós. Gracias.