Haciendo la menor cantidad de trabajo posible: Una introducción al rendimiento en tiempo de ejecución

Entonces, comencemos preguntando qué es el rendimiento en tiempo de ejecución. Y no se escucha tanto en comparación con otras cosas, ¿verdad? Muchas veces, cuando hablamos de rendimiento, cuando escuchas a, ya sabes, supongo que serían devrels o defensores de la plataforma, el rendimiento que están defendiendo es el rendimiento de carga, ¿verdad? Como muchas conversiones y retenciones y cosas así. Todo se reduce a qué tan rápido se carga tu sitio y, ya sabes, tu tiempo de interacción y cosas así. Tienes todas estas métricas de Lighthouse y eso es lo que se optimiza en gran medida, ¿verdad? Ya sabes, ves cosas como puntuaciones de Lighthouse, core web vitals ahora integrados en create React app. Cosas como el peso de la página, ¿verdad? A todos les preocupa la división de paquetes y mantener el control del tamaño de los paquetes. Y eso también se traduce en cosas como el tiempo que lleva analizar JavaScript, como si tienes mucho JavaScript que estás sirviendo, ¿verdad? Primeras pinturas significativas, ¿verdad? Tienes estas referencias de qué tan rápido está llegando tu sitio y lo más importante, creo, es el tiempo de interacción, que es el tiempo hasta que alguien realmente puede comenzar a usar tu aplicación o tu sitio. Están listos para comenzar.

Aunque esas son métricas muy importantes y están muy bien documentadas, eso no es de lo que trata esta charla. Se trata de mantener la interactividad, ¿verdad? Una vez que hayas cargado todo, una vez que hayas cubierto tus bases, dependiendo de lo que haga tu aplicación o tu sitio, lo que quieres hacer al final del día es seguir siendo interactivo después de haberlos llevado a ese punto significativo, ¿verdad? Y la pieza clave de eso es no bloquear tu hilo principal.

En JavaScript, tienes un hilo principal, y es donde ocurre la mayor parte de la actividad. Y si lo bloqueas, verás cosas como las animaciones que se traban, escribir en los campos de entrada y habrá retraso. Todas estas cosas afectan negativamente la experiencia de usuario de tu sitio o aplicación, y no quieres eso. Los problemas típicos que puedes ver, como tareas computacionalmente costosas, si tienes que operar o clonar un montón de objetos grandes o algo así, las animaciones es donde lo verás. Muchas veces, tienes que empezar a escribir o intentar hacer clic en algo o hacer un hover para verlo, pero si tienes una animación en curso, lo verás casi de inmediato si se hace de cierta manera, así que se trabará. Y ni siquiera tiene que ser, ya sabes, 900,000 objetos. Todo tu sitio puede trabarse solo por Reflow, Repaint y Layout. Estaba viendo un sitio de un amigo el otro día, y no tenía JavaScript, pero el sitio iba lento. Era la API de animaciones web, solo estaba ocurriendo el diseño del navegador. ¿De acuerdo? Otras cosas son el análisis, ¿verdad? Si estás analizando búferes grandes o JSON, eso lleva tiempo. Es una tarea computacionalmente costosa. Y mi menos favorito de todos, que probablemente tengas menos conocimiento y requiera un verdadero trabajo de detective, son las fugas de memoria. Son devastadoras. Pero nuevamente, eso se vuelve muy evidente. A menudo, no muy rápidamente. Tienes que sentarte allí durante, ya sabes, una hora, y ahora la cosa se ralentiza. Y luego dices, oh, chico, tienes un problema de CSS, actualizas y puedes decir, cambié esto, cambié aquello con una fuga de memoria. Tienes que esperar una hora solo para reproducirlo. Es difícil.

Entonces, ¿cómo sabes si tienes un problema de rendimiento? Obviamente, escribes tu perfil, pero muchas veces, si realmente es un problema, lo sabrás. En cuanto a lo que se habla mucho sobre la optimización prematura, cosas así. Si tienes un problema de rendimiento, muchas veces se vuelve bastante evidente. Tu cosa será lenta, a menos que te acostumbres a que sea lenta. Pero eso es otra charla, ¿verdad? El mejor escenario es que verás muchos cuadros caídos y cosas como retraso en la entrada. Esos serán los principales indicadores de que tienes un problema. El peor escenario es un aw snap, ¿verdad? Y luego esto es donde se volvió un meme, y sabes, está bloqueando por completo tu sitio web. Así que esos dos puntos y cualquier cosa intermedia indican que probablemente deberías echar un vistazo al código y pensar en optimizarlo.

Entonces, ¿cómo lo solucionas? Has identificado que hay un problema. No estás seguro de qué es, pero ¿cómo lo solucionas? Y te diré ahora mismo que gran parte de ello es como un trabajo de detective.

El rendimiento no es prescriptivo en el sentido de que no puedo darte una lista de verificación de cosas como puedo hacer con, ya sabes, como Lighthouse. No puedo decirte, bueno, ya sabes, ¿haces la división de paquetes y pones esto en la cabeza y esto al final? Ya sabes. Muchas veces es un problema que has creado con la forma en que lo has codificado. Y tienes que desenredarlo, ¿verdad? Es algo en lo que tienes que ser ingenioso. A veces es la realidad de los requisitos de la aplicación. Y luego tienes que encontrar un compromiso o una forma astuta de hacer menos trabajo. ¿Verdad? Cuando optimizas el rendimiento, si quieres que vaya mejor, haces la menor cantidad de trabajo posible. No tú personalmente, tu aplicación. Quieres hacer la menor cantidad de trabajo posible para alcanzar tu objetivo. De lo contrario, tendrás ineficiencias, y a gran escala, explotarán. ¿Verdad?

Hay algunas cosas semi-prescriptivas en las que puedo entrar. ¿Verdad? Obviamente, tiene que aplicarse a tu situación, pero... Cosas como usar un bucle for regular. Si dices, oye, esto tarda demasiado, ¿cómo puedo hacer que vaya más rápido? ¿Dónde puedo ganar un poco aquí? Si estás aquí haciendo todas estas cosas elegantes con todos estos mapas encadenados y todo esto, esto y aquello, si lo haces en un bucle for regular, a la escala en la que importaría, definitivamente puedes recuperar algo de tiempo usando eso. Muchas operaciones de matriz, ¿verdad? Como si estás haciendo una búsqueda en una matriz o algo así, ¿verdad? Uno de tus mayores enemigos en la optimización del rendimiento es la iteración. Especialmente la iteración innecesaria. Así que si tienes una matriz de, digamos, 500,000 elementos, y vas a hacer una búsqueda en ella, o haces cualquiera de estas operaciones de prototipo de matriz que recorrerán todo el conjunto hasta que salga o se complete, eso es costoso, ¿verdad? Así que si tienes, digamos, un ID, digamos, tengo este ID, quiero encontrar esta fila que tiene este ID. Puedes crear una tabla de búsqueda. Y una tabla de búsqueda es un término estúpido para, quiero decir, tal vez no sea un término estúpido, pero si, ya sabes. Es un objeto, ¿verdad?, donde la clave, ¿verdad?, sería tu clave, como un ID, como la cosa que quieres buscar, ¿verdad? Y luego podrías tener el valor de eso como la posición de índice de tu cosa en la matriz, ¿verdad? Así que es una forma muy económica de encontrar esa cosa, ¿verdad? Entonces estás diciendo, oh, bueno, tengo que actualizar el ID de la cosa igual a esto, digamos, oye, busca dónde está. Y es solo, bap bap, bap bap, y luego estás listo. En lugar de decir, encuentra con una función de predicado que busca el ID o algo así. Otra cosa que debes tener en cuenta, especialmente, especialmente costosa, es la creación de un montón de objetos nuevos. Y eso son objetos y matrices, ¿verdad? Hay muchas cosas elegantes sucediendo en el desarrollo en estos días con ES6 o Next o como sea que lo llamemos en estos días, donde se usan spreads todo el tiempo y los spreads crean nuevos objetos, ¿verdad? Así que si estás lidiando con cosas en la escala de cientos de miles de cosas, y estás creando nuevos objetos, lo que eso va a hacer es forzar la recolección de basura y también los costos de asignación, pero eso va a arruinar tus cosas, ¿verdad? Si puedes hacer una mutación directa, y sé que es una palabra sucia, pero si puedes hacer una mutación directa, puedes obtener algunos ahorros. Una alternativa es usar algo como Imr, donde tienes compartición estructural, ¿verdad? Donde no se realiza una clonación para hacer una actualización, ¿verdad? No es necesariamente una mutación o imperativo, pero es una forma de hacerlo que es mucho más barata. Una cosa realmente divertida de la que quiero hablar por un segundo es el rendimiento percibido, ¿verdad? Así que hay un rendimiento donde las cosas son realmente lentas y realmente bloquean el hilo principal, pero también hay escenarios en los que puedes hacer que las cosas parezcan más rápidas sin que realmente lo sean. Y puedes hacer eso desactivando la animación en muchos casos, ¿verdad? Así que si, tenía una aplicación en la que la estaba rediseñando y la gente decía, wow, ahora va súper rápido. ¿Qué hiciste? Y simplemente desactivé la animación, ¿verdad? Si tienes esta cosa de hover animado, aunque se vea genial, ¿verdad?, la percepción mientras lo recorres es que es más lento. Si todo es retroalimentación instantánea, se siente más rápido. Así que el rendimiento percibido, ya sabes, es como volver a la suspensión con la cosa del spinner de carga.

Hay algo que decir sobre el rendimiento percibido, especialmente en el área de la experiencia de usuario. Otra cosa en la que puedo entrar es evitar los reflows y los layouts. Y lo mostraré en un momento, cómo puede suceder eso. Sí, ni siquiera necesitas que cosas costosas estén sucediendo. Si estás animando cosas o mostrando y ocultando cosas, y eso hace que el navegador se redibuje, eso no es bueno. Eso va a... eso ni siquiera necesita cálculos porque el redibujo del navegador va a interrumpir todo.

El almacenamiento en caché es una forma sencilla de mejorar el rendimiento en tiempo de ejecución. Muchas veces, verás que en cada renderizado, la gente llamará a un formato de fecha o algo así, y un formato de fecha es costoso, o crear un objeto de fecha. Si puedes memoizar eso, si no están cambiando y no esperas acumular esta caché de 2GB de objetos de fecha, entonces lo que estás haciendo es un truco astuto, donde dices, voy a formatear estas fechas una vez, y luego cualquier llamada posterior al formato para esa fecha, si estamos renderizando esto, si hacemos clic en una casilla de verificación y solo está habilitada o no, no tiene nada que ver con el cambio de fecha. Va a mostrar la cadena BAP BAP, y no vas a tener este impacto en cada elemento que se formatee con fecha.

Y luego están los detalles. Muchas veces, son exagerados. Pero cuando realmente estás buscando cosas, especialmente en iteraciones con una gran cantidad de filas, hacer algo como si vas a eliminar muchas cosas de un objeto, es mucho más rápido establecerlo como indefinido en lugar de usar la palabra clave de eliminación real. Y como cualquier otra cosa en el rendimiento, hay un compromiso, donde esas cosas seguirán surgiendo y tendrán su propia propiedad o algo así. Pero luego solo tienes que tener cuidado con eso, porque hay un compromiso para todo.

Entonces, quiero hablar solo por el resto de esta charla sobre el perfilado, porque eso es cómo vas a resolver estos problemas. Y más allá de las cosas semi-prescriptivas que acabo de mencionar, quieres encontrar tu problema e identificarlo para poder comenzar a diseñar una solución, ¿verdad? Y algunas de las herramientas que voy a mostrar y que vamos a usar son la pestaña de rendimiento de Chrome, la pestaña de memoria de Chrome para las fugas de memoria, tu monitor de rendimiento, que es muy útil con la CPU, y la API de tiempos de usuario, que es increíble. Así que aprendamos cómo usar las herramientas de desarrollo un poco. Tengo esta pequeña aplicación de React aquí. Y aquí voy a crear un millón de filas en un array en esta lista inicial. Y luego simplemente las vamos a agregar, ¿verdad? Y luego iba a hacerlo en vivo, pero no lo voy a hacer ahora porque se nos está acabando el tiempo. Y quiero llegar a esto. Así que tenemos esta lista, esta lista inicial, un millón de cosas, ¿verdad? Tiene un ID y un valor que es aleatorio. Y luego simplemente lo vamos a usar como estado aquí con el valor inicial, ¿verdad? Luego en el montaje, ¿verdad? hacemos un intervalo. Cada 500 milisegundos, lo que voy a hacer es llamar a set list con nuestra lista, ¿verdad? Así que esto va a... esto es un set state, ¿verdad?, con la lista. Voy a expandir esa lista, clonarla para crear esta nueva lista. Y luego voy a iterar y expandir los valores antiguos en esta expansión. Recuerda lo que dije sobre las expansiones, así que ahora obtendrá su ID, que, ya sabes, Ridículo porque es solo el índice, pero es algo ficticio, aguanta conmigo.

Y luego simplemente vamos a agregar un nuevo valor y luego vamos a devolver la nueva lista. Así que estamos actualizando esa lista aquí cada 500 milisegundos de un millón de cosas, ¿verdad? Así que veamos esto. Y te voy a mostrar cómo perfilar esto, ¿verdad?

Así que tenemos nuestra aplicación lenta aquí. Voy a abrir mis herramientas de desarrollo aquí. Y vamos a echar un vistazo, porque vamos a aprender cómo leer esto hoy. Presionas grabar, ¿verdad, y comenzará a perfilar tu rendimiento en tiempo de ejecución. Presionas detener. Y ahora podemos mirar aquí. Y si ves, primero que nada, este es tu hilo principal. Voy a explicarlo por un segundo. Este es tu rasterizado, tu GPU, tu compositor. Si tienes trabajadores, estarán en una línea separada. Ahora está teniendo un momento realmente malo aquí. Puede que deje esa cuenta regresiva.

Cada uno de estos aquí es una de esas actualizaciones que estás viendo. Va a ir de padre a hijo en la llamada, ¿verdad? Así que verás que tengo esta función anónima aquí. Va a ejecutar un montón de cosas internas de React. Va a intentar renderizar la aplicación en respuesta al estado. Llegamos aquí a nuestro reductor de estado. Estas son las partes internas de eso. Y luego verás esto. Todos estos son anónimos porque no es una función con nombre. El reductor en ese conjunto de listas. Pero estás viendo esto y cuando creamos tantos objetos nuevos, ahí es donde tienes esta recolección de basura. Eso lleva 10 milisegundos, ¿verdad? Así que para hacer eso, ¿verdad? Estamos viendo 375 milisegundos. Cuando miras aquí arriba y ves esto en rojo, eso significa que estás bloqueado, ¿verdad? Y verás aquí abajo, dirá tiempo total de bloqueo. Así que te lo mostrará. Y tienes una enorme cantidad de fotogramas perdidos aquí. El rojo es malo. Y quiero decir, si vamos y miramos, creo que lo está pasando bastante mal en este momento.

Entonces podemos ir a más herramientas y podemos ir al monitor de rendimiento, ¿verdad? Y nos dirá que casi estamos, ya sabes, al 100% de CPU aquí y allá. El montón de memoria es enorme, no hay tantos nodos DOM.

Así que volvamos por un segundo. Voy a reducir esto a 20,000. Muy bien. Y luego podemos venir aquí y ya no es tan malo. Órdenes de magnitud menos, pero aún no es genial. Vamos a ejecutar un perfil nuevamente. Muy bien. Así que para menos cosas no es tan malo, pero aún es bastante malo. Son 60 milisegundos, eso es como varios fotogramas perdidos. Podemos ir y mirar la memoria aquí. Y así es como depuramos las fugas de memoria, ¿verdad? Si tomas una instantánea aquí, una instantánea del montón de memoria. Um, una forma común en la que lo haré. Hay muchos objetos aquí, así que está pensando y estoy compartiendo pantalla. Dios, relájate. Sí, así que tienes aquí. Y luego lo que puedes hacer es ordenar por tamaño superficial o retenido. Y luego, si tomas instantáneas posteriores, puedes ver qué es qué. ¿Qué está sucediendo? Además, incluso puedes ir y, um, si haces dos, ¿verdad, hay una buena diferencia? ¿Verdad? No lo voy a hacer de nuevo porque lleva tiempo, pero así puedes ver los objetos asignados antes de las instantáneas. Puedes ver las diferencias de, ya sabes, qué se está acumulando aquí. Y eso es bastante útil. Um, espera.

Entonces aquí, ¿verdad? Sabemos que nuestro problema está, ya sabes, en esta función anónima. Pero el problema es que esto se cuantifica en, um, estos bloques. Entonces lo que queremos hacer es examinar los detalles minuciosos y la forma en que lo haríamos, lo que voy a hacer es poner 5,000 solo para que no sea tan devastador. Pero lo que podemos hacer aquí es usar lo que se llama la API de tiempos de usuario. Y es increíble. Entonces puedes hacer performance.mark, ¿verdad? Y lo llamaremos inicio de clonación de lista.

Y luego podemos bajar aquí y puedo decir performance dot mark, list clone stop. ¿Verdad? Y luego aquí puedo decir para cada uno de estos, bueno, antes de hacer eso, diré performance dot measure, ¿verdad? Y tienes tu nombre de medida, así que lo llamaremos list clone. Y luego tienes tu inicio y fin, que serán list clone start y list clone stop. Aquí abajo diré performance dot mark y lo llamaremos uno y dos, ¿verdad? Lo llamaremos uno y dos, ¿verdad? Y puedo guardar ahí, luego podemos volver aquí. Probablemente me regañe. Vamos a refrescar, volver aquí. En lugar de agruparse en las cosas salvajes, en realidad vamos a poder ver de manera detallada lo que está sucediendo aquí, lo cual te ayudará en tu perfilado. Esto puede llevar un segundo. Puedes hacerlo. Puedes hacerlo, creo en ti. Bien, voy a hacer uno más rápido. Nadie tiene tiempo para eso. Ven aquí. Bien, ahora estamos hablando en serio. Aquí, arriba de main, ves una nueva cosa llamada timings, ¿verdad? Y anteriormente, cuando miramos aquí y miramos aquí abajo, y vemos estos anónimos, eso es donde se detuvo. Ahora puedes ver de manera detallada lo que está sucediendo aquí. Así que tienes la marca de medida, eso está ahí. Pero si vamos arriba a los tiempos aquí, podemos hacer zoom. Y podemos ver exactamente cuánto tiempo toman estas cosas. Como esta es una iteración, ¿verdad? Así que ves el uno, dos, iteración, y eso está en eso está en microsegundos. Estoy tratando de ver si puedo ver uno de los clones. Probablemente esté al principio aquí. Sí, ves que el clon de la lista toma una fracción de milisegundo. Obviamente, si estuviéramos en un millón, habría bastantes de estos, y probablemente solo haría el clon en lugar de los individuales. Pero sí, esta es una excelente manera de ver de manera detallada qué está causando problemas. Ahora ya me pasé de tiempo, pero antes de irme, te mostraré un ejemplo de cuando ni siquiera es JavaScript el que lo está haciendo. ¿Verdad? Así que antes, y veamos, cuando vamos aquí, ¿verdad?, estás viendo información en el resumen aquí, y luego dirá el tiempo agregado y casi todo es scripting, ¿verdad? Eso te está diciendo que tu JavaScript es el problema, pero muchas veces JavaScript no es el único culpable aquí. Tenemos este bribón girando y esta animación se realiza en un hilo diferente, así que no es un problema, ¿verdad? También está utilizando transform, ¿verdad? Así que está compuesto, lo que significa que se dibuja como una capa encima de tu sitio web. Cuando usas translate o rotate, en realidad no se actualiza el diseño, no se mueven las cosas en la pantalla, es como si estuviera en su lugar.

Entonces, si haces una traducción, ¿verdad?, el área donde está todavía está ahí. Simplemente está arriba, ¿verdad? Porque se está componiendo, ¿verdad? Entonces no hay un impacto en el rendimiento allí, y por eso dicen que uses las transformaciones si no quieres que sea brusco. Pero si vengo aquí y hago algo que fuerce el diseño, como animar la altura, por ejemplo, si viniera aquí y dijera altura y vamos a ir de 200 píxeles de altura a 400 píxeles, ¿verdad? Y venimos aquí, ¿de acuerdo?, verás que se mueve de manera brusca, ¿verdad? Puede que no lo puedas ver en la transmisión, pero lo que está sucediendo es que cuando esto se hace más grande, el sistema de diseño interno del navegador tiene que recalcular dónde se supone que debe ir todo esto. Entonces, si vuelvo aquí y ahora perfilamos esto, va a contar una historia muy diferente. Probablemente no tan claramente como lo hizo con las cosas más caras. Pero si entramos aquí, ¿verdad? Lo que verás es mucho verde y morado. Y lo que eso es y ver todas estas caídas de fotogramas, lo que está sucediendo es el cálculo de estilos, el diseño y luego el repintado, lo que significa que el navegador constantemente tiene que volver a dibujar todo lo que estás viendo porque la altura está cambiando, lo que invalida el diseño. Y puedes ver aquí que dice renderizado, pintura, y no solo eso, puedes ver que el compositor aquí se está volviendo loco y estás obteniendo impactos en la GPU aquí en los repintados. No necesitas JavaScript para arruinar tu rendimiento en tiempo de ejecución. Puedes hacerlo todo por tu cuenta solo con CSS.

Así que espero que hoy haya hecho un buen trabajo poniendo el foco en el rendimiento en tiempo de ejecución y también explicando un poco mejor las herramientas de desarrollo y brindándoles las herramientas que necesitan para que sus sitios sigan siendo interactivos y rápidos.

Muchas gracias a todos. Increíble. Muchas gracias por esa genial charla. Realmente la disfruté mucho. Espero que ustedes también. El increíble Ken Weaver.

Vamos a ver una pregunta que Ken nos hizo anteriormente. Ken preguntó si han utilizado el panel de rendimiento en Chrome DevTools. ¡Y la encuesta dice que sí! El 64% de ustedes dijo que sí, pero no están seguros al 100% de cómo funciona. El 22% de ustedes sabe o dijo que sí, y sabe cómo funciona. Y el 14% dijo que no. Los recomiendo encarecidamente. Creo que son geniales. Definitivamente, pruébenlos. Pero antes de continuar, voy a invitar a Ken a responder sus increíbles preguntas. Ken, ¿cómo estás? Estoy sobresaliente. ¿Cómo estás? Estoy bien, estoy bien. ¿Sabes qué? Me encanta tu configuración. Me encantan las vibraciones. Puedo imaginar que suenan algunos ritmos lo-fi de fondo. Solo una pregunta rápida. Esto es solo para mí. ¿Cuál es tu tipo de música favorita para escuchar mientras te relajas? Cuando estoy relajado o cuando estoy programando? Ambos. De acuerdo. Entonces, si estoy programando, no me gusta la música con letras, ¿verdad? Escucharé ritmos lo-fi o la banda sonora de Westworld, ese tipo de cosas. Álbumes de Trent Reznor o algo así. Porque no requiere mucho procesamiento. Pero si solo estoy relajado, generalmente escucho música trap divertida o algo así.

¡Increíble! Genial, genial. Podría hablar de música contigo todo el día. Pero tenemos algunas preguntas de desarrolladores reales que quiero responder. La primera me parece graciosa, pero de todos modos la voy a hacer. Si sospechas de una fuga de memoria, ¿intentas debugearla o la aplastas con una revisión de código o haces algo más? ¿Cuál es el primer enfoque para lidiar con ello? Si sospecho de una fuga de memoria, voy a buscar un vaso de agua o café o algo así. Porque la mayoría de las veces, cuando me encuentro con fugas de memoria, sabes, es algo en lo que tienes que sentarte durante unos 45 minutos para reproducirlo. Sabes, como rara vez es una de esas cosas en las que, simplemente, obtienes el OSNAP y el navegador se bloquea, ¿verdad? Siempre es algo que, durante 45 minutos, se detiene en seco. Entonces, bueno, sabes, voy a sentarme aquí y hacer otra cosa mientras tomo instantáneas aquí y allá y luego podemos ver qué se acumula. Definitivamente he estado en esa posición tratando de encontrarla antes. Y a veces puede ser una porquería.

¿Tenemos otra pregunta de W Warrior? ¿Qué opinas sobre bibliotecas como Immutable.js que crean nuevos objetos por diseño? Quiero decir, Immutable es genial, pero ahora Immer es mi elección principal. Respondiste la segunda pregunta que era, ¿ves alguna alternativa? ¿Hay algo específico que te guste de ella? Es bastante sencillo, ¿verdad? Usas la función produce y luego editas mutativamente lo que quieras hacer y lo aplica. Bueno, bueno. Tenemos otra pregunta de Pop Linguy. ¿Las herramientas de rendimiento de Firefox podrían ser una competencia de las herramientas de desarrollo de Chrome? Comparar las dos. Honestamente, no puedo hablar de eso. No he usado Firefox en bastante tiempo. Pero la última vez que lo revisé, tenían algunas características interesantes. Lo mismo se puede decir de Safari. También tienen algunas cosas interesantes para depurar gráficos. Pero paso el 99.9% de mi tiempo en Chrome. Sí, lo mismo aquí.

Soy un gran fan de Chrome. Alguien preguntó sobre diferentes fugas de memoria que has solucionado. ¿Has visto alguna similitud o tendencia común entre ellas? Bueno, una cosa que ocurre con frecuencia son los listeners, ¿verdad? Si agregas listeners y luego no los eliminas, eso ocurre mucho. Otras veces, simplemente puedes tener algo que se acumula con el tiempo, ¿verdad? Por ejemplo, si almacenas en caché algunos datos cada vez que cargas una página, ¿verdad? Pero si es una aplicación de una sola página y hay cientos de páginas, si navegas por cientos de páginas y esa caché no se borra periódicamente, dependiendo de lo que haya allí, no solo es el marcado, sino también si estás cargando conjuntos de datos de 500,000 filas para cada cosa y navegas entre ellos, eventualmente se acumulará. Otras veces, es simplemente iteración y temporizadores, ¿verdad? Si tienes datos en tiempo real y estás iterando a través de ellos, las pequeñas cachés y almacenes pueden acumularse.

Genial. Tenemos otra pregunta. Es otra pregunta de broma, pero me siento obligado a leerla, así que lo haré. Dice: ¿Haces una comprobación regular de tu perfil de memoria o esperas a que los problemas llamen a tu puerta? No, depende, ¿verdad? Como si estuviera haciendo una broma de Ken Wheeler, como si estuviera haciendo un kenwheeler.blog, no estoy revisando realmente la CPU en eso, pero si estoy haciendo un control de lienzo de alto rendimiento o algo así, definitivamente voy a mirar anticipadamente dónde está la CPU, en las primeras etapas del desarrollo, solo para asegurarme, ya sabes, establecer líneas de base para que más adelante, a medida que se vuelve más complejo, ¿verdad? Puedas decir, ya sabes, ¿qué estamos obteniendo y qué estamos perdiendo? Tiene sentido. Y la última pregunta, alguien llamado Alex, agradeció que compartieras cómo las animaciones pueden afectar el rendimiento. Las animaciones aún pueden ser muy importantes, así que están preguntando si deberían usar animaciones con moderación o si hay otras técnicas para tener animaciones de alto rendimiento. Creo que no todas las animaciones son malas. Las que debes tener cuidado son las animaciones que están vinculadas a la interactividad del usuario, ¿verdad? Por ejemplo, si estás moviéndote a través de algo, resaltando algo o resaltando filas, no animaría eso porque retrasa la retroalimentación de la acción. Pero si quieres tener una animación al estilo de Josh Camus, algo caprichoso, adelante. Eso es genial. No está necesariamente vinculado a eso, ¿verdad?