Perfeccionando Tu Perfilado

Un poco sobre mí. Tengo cuatro hijos y dos perros, así que el profiling de la vida es muy importante, pero desafortunadamente no parece que nadie haya creado unas DevTools para la vida. Si lo has hecho o si esa es tu idea de negocio, házmelo saber. Seré uno de tus beta testers.

Pero en mi capacidad profesional, trabajo en AGGrid y ahora tenemos tanto AGGrid como AGGcharts. Así que estos son componentes de React que puedes incorporar en tu aplicación y todo está incluido, tienes tu grid, lanzas tus datos, tienes tus charts, y puedes producir estas hermosas visualizaciones con muy poco esfuerzo en absoluto. Así que si quieres saber más sobre eso, ven y habla con nosotros en el stand.

Pero sé que la verdadera razón por la que estás aquí es para hablar sobre el profiling. Así que esto va a ser o esto fue el contenido de mi charla hasta hace unas semanas. Así que voy a comenzar con las React DevTools. Vamos a ver el panel de rendimiento de la extensión Web Vitals en Chrome y luego voy a lanzarte algunos consejos rápidos de cosas que he aprendido mientras hacía profiling en AGGrid.

Pero como dije, esta era la charla y luego Chrome hizo una gran actualización donde desaprobaron la extensión Web Vitals y la han movido al panel de rendimiento y ahora se llama la vista de métricas en tiempo real. Así que este es un cambio realmente emocionante porque está trayendo todas estas características y usabilidad que creo que estaban subestimadas y poco utilizadas en la extensión Web Vitals directamente a tu panel de rendimiento. Y espero que al final de esta charla veas lo valiosa que puede ser esa información para ti.

Así que, en primer lugar, las React DevTools. Ahora esto dice que se ha descargado 4 millones de veces, así que supongo que casi todos aquí la tienen descargada. Sí, eso es bueno. Como muchos de ustedes aquí la han descargado y la están usando. Un poco más silencioso. Así que sí, una vez que hayas instalado la extensión tendrás este profiler y también una opción de componentes en tus DevTools. Así que puedes encontrarlo allí. Podrías encontrarte con este problema inicialmente diciendo que el profiling no es compatible. Así que asegúrate de que tu versión de React sea lo suficientemente reciente y también que estés en modo de desarrollo porque no puedes hacer profiling contra producción porque este profiling dentro de React añade retrasos y trabajo adicionales. Así que React lo elimina en producción para que tus aplicaciones sean lo más rápidas posible. Así que vas a estar desarrollando contra el modo de desarrollo de React, que debes recordar hace comprobaciones adicionales, pero entonces React también tiene esta versión de código con punto profiling. Así que no hace todas las comprobaciones de desarrollo pero aún tiene el profiler para darte la información.

Pero una vez que hayas hecho eso y esté funcionando, puedes grabar un perfil. Así que aquí en esta versión beta de AgGrid estaba haciendo algunas pruebas de rendimiento al arrastrar columnas y redimensionarlas. Así que grabé el perfil, hice mi acción y luego aquí tenemos este perfil. Así que podemos mirar a través de los diferentes marcos, así que cada una de estas barras o 254 de ellas son renders individuales, y podemos bajar e interactuar con este flame chart y hacer clic en estas cosas individuales y ver, ¿de acuerdo, qué componente es? Y también esto va demasiado rápido, vamos a ralentizarlo. O no lo haré, volveré a ello en un momento.

Y luego puede profundizar en eso y decir, de acuerdo, ¿de este componente qué hook está causando que se renderice mucho? Así que lo que tal vez viste aquí o tal vez no se dio cuenta es que lo que hay que llevarse de este perfil fue que hay mucho renderizado sucediendo mientras estamos redimensionando estas columnas. Y luego podemos bajar a ese flame chart y nos da los nombres de los componentes y podemos hacer clic en él y dirá, bueno, el hook 30 cambió. Y luego, una vez que hayas hecho clic en el componente puedes realmente hacer clic desde el perfil a los componentes, supongo, pestaña en tus dev tools y luego mirar la lista de todos los hooks.

Y para nosotros el número 30 es este ancho de estado. Así que es una forma muy rápida que nos ha permitido identificar el hook de estado exacto que está causando que nuestro componente se re-renderice. Así que luego podemos sumergirnos en ese código y veremos algo como esto. Estábamos usando la propiedad de ancho que se estaba actualizando para luego cambiar el estilo en este en este elemento div. Y así cada vez que el estilo estaba cambiando, ya sabes, mientras estábamos arrastrando cosas alrededor, React estaba re-renderizando todas estas celdas y así esos eran los 254 tipos de eventos que se estaban disparando. Así que realmente podemos hacer estos cambios y este es el tema de toda otra charla. Podemos simplemente cambiar este estilo directamente. No estamos cambiando ninguna de la estructura de React solo estamos identificando este elemento DOM y diciendo que realmente vamos a encargarnos del estilo y solo vamos a ajustar el ancho. No necesitamos que todo se re-renderice, solo vamos a cambiarlo y el resultado de eso es que ahora en Azure Grid cuando estás redimensionando columnas no hay re-renderizado. Así que aquí hay dos renders aquí en lugar de los 254. Así que estás obteniendo una experiencia mucho más fluida, mucho más como una experiencia nativa con estos movimientos de las columnas. Y todo esto fue muy fácil de diagnosticar a través de las React dev tools. Y estas son algunas configuraciones importantes que necesitas habilitar para darte esta información útil. Así que en el profiler puedes decir grabar por qué cada componente se re-renderizó mientras se hace profiling. Eso no está activado por defecto, creo. Así que si activas eso entonces te da esa información de que realmente fue el hook 30 el que causó que este componente se re-renderizara. Así que esta es información realmente clave. Y luego también hay esta otra parte bajo el panel de componentes que dice, ya sabes, analizar los nombres de los hooks. Así que en lugar de a la izquierda donde solo tienes estos estados y sus valores, realmente obtienes el nombre. Así que de nuevo esto solo te va a hacer mucho más productivo al poder decir, de acuerdo, fue este hook y luego este es realmente el que en mi código sé que necesito mirar. Y luego también otra cosa útil que creo hemos visto en algunas de las charlas anteriores es que incluso si no estás haciendo profiling puedes habilitar esta bandera para resaltar las actualizaciones. Y de nuevo podríamos verlo aquí, comenzamos a arrastrar las columnas y puedes ver todas estas celdas re-renderizándose.

Así que nos da, supongo, una forma más rápida de simplemente interactuar con nuestra aplicación y ver todas las cosas que están cambiando. Así que pensé que este era un video útil si quieres verlo en tu propio tiempo. Y hay bastantes videos por ahí, creo que este tiene una buena mezcla de contenido y también profundiza en los diferentes formatos de los gráficos que puedes usar dentro de los React DevTools. Así que recomendaría ver ese para una charla un poco más pausada.

Otra cosa que quiero cubrir son los Core Web Vitals. Así que estos son métricas que son realmente importantes para tu aplicación, especialmente si estás buscando mejorar tu SEO, tu resultado en la búsqueda, porque es como Google clasificará tu sitio web. Así que es realmente importante que hagamos métricas por esa motivación, pero también da a tus usuarios una mejor experiencia. Así que tienes beneficios en ese sentido, la gente querrá volver y usar tu sitio. Y en la que me voy a centrar es en la interacción al siguiente renderizado. Así que esto es nuevo desde marzo de este año y observa la latencia entre cuando un usuario interactúa con tu sitio y cuando realmente obtiene algún feedback visual.

Así que no es necesariamente que tu sitio pueda, o para nosotros como educadores, la cuadrícula filtrará todos los datos muy rápidamente. Es más que si el usuario está escribiendo algo para activar ese filtrado, verá todo el filtrado que está escribiendo y no será como entrecortado, porque la cuadrícula está interfiriendo con que el navegador pueda re-renderizar. Esto es algo que React Concurrency y todas esas características concurrentes pueden realmente ayudarte a hacer y mejorar. Así que como iba a decir, la extensión Web Visuals era una muy buena forma de ver esta información, pero ha sido discontinuada. Así que creo que es importante notar aquí, esto solo ha sido descargado unas 100,000 veces, comparado con los 4 millones de veces, o incluso más de 4 millones, que los React DevTools han sido descargados. Así que está claro que la información aquí simplemente no está llegando a la amplia audiencia que podría. Así que por eso creo que es realmente emocionante, gracias a la versión 129 de Chrome, mucha de esta información se está moviendo directamente a tu panel de rendimiento en lo que están llamando, vista de métricas en tiempo real. Así que en esto, veremos, abriré un perfil en un momento, pero te está dando la misma información y también hay algunas formas realmente útiles de que puede compararlo con tus datos de campo si tu sitio web cumple con los criterios para la base de datos crux. Y también entonces puede decirte, bueno, en realidad, tu máquina de desarrollo, tu interacción a Nextpaint podría ser realmente buena, pero comparado con lo que estamos viendo como tráfico real en tu sitio web, es muy diferente.

Así que tal vez entonces deberías habilitar algunas de estas configuraciones de limitación. Así que puedes ralentizar tu red, ralentizar tu CPU, y luego volver a ejecutar tus pruebas y ver qué podrían estar experimentando los usuarios reales en tu sitio web.

Así que este es un ejemplo que funcionaría en el panel de rendimiento, pero esto está usando la extensión Web Vitals. Así que cuando estábamos probando, estaba probando esto en nuestro sitio web y escribiendo en este filtro rápido. Así que el filtro rápido luego pasó ese texto fuera de la cuadrícula para filtrar, creo que en este caso eran cien mil filas. Y lo que la extensión Web Vitals y también lo que verás en la lista de interacciones en tu panel de rendimiento es que comenzarás a obtener estas interacciones rojas, diciendo bueno en realidad el tiempo entre que el usuario escribe y ve que el navegador repinta es demasiado largo. Y así no tienes que perfilar ni nada, solo puedes abrir esto, comenzar a interactuar con tu sitio web y ver cuando esto se pone rojo.

Así que lo que estaba pasando aquí es que el texto del filtro rápido se estaba pasando directamente a la cuadrícula y así cada vez que el texto del filtro rápido cambiaba, la cuadrícula estaba entonces refiltrando todo. Y así lo que podemos hacer es simplemente deferir este texto del filtro. Usamos el hook use deferred value y luego lo que este hook va a hacer es decir bueno en realidad este valor no es crítico que se actualice inmediatamente y de manera sincrónica. En realidad lo que quiero que hagas es asegurarte de que el navegador tenga la posibilidad de actualizar y re-renderizar. Y mientras el navegador está, mientras estamos cediendo al navegador para hacer eso, solo espera con este valor diferido, el último, hasta que el navegador haya terminado de hacer su trabajo y luego puedes continuar con tu filtrado. Y así si hacemos ese simple cambio ahora podemos ver, podemos escribir en este cuadro de filtro, estamos viendo cada pulsación de tecla y solo estamos obteniendo registros de interacciones verdes a la siguiente pintura. Así es como puedes usar esas métricas para interactuar con tu sitio y ver dónde están las cosas que necesitas mejorar.

Y una vez que has hecho eso, o has trabajado a ese nivel, a veces necesitamos ir aún más profundo. Y esto es, esa es la frase de la conferencia, ¿no es así?, vamos a profundizar. Así que el Panel de Rendimiento de Chrome DevTools, cuando comienzas a grabar estos perfiles, es cuando realmente puedes profundizar.

Puedes encontrar métodos individuales que están tomando más tiempo del que esperabas, o puedes comenzar a adentrarte en el mundo de diseños forzados y css y todos estos tipos de problemas de thrashing que podrías encontrar. Así que esto es algo que he hecho para EduGrid también. Así que estoy aquí perfilando el rendimiento de nuestro desplazamiento, y la cuadrícula aquí es la de vanilla js. Así que he grabado el perfil y luego obtenemos esta tabla. Y lo que realmente vamos a hacer es sumergirnos en esto juntos. Así que puedes guardar perfiles en, una vez que los has grabado, y luego cargarlos y compartirlos. Así que tenemos esta vista. Así que este fue el resultado de crear un perfil mientras estábamos desplazándonos. Y lo que podemos hacer es acercarnos aquí a una sección particular.

Podemos ver que tenemos todas estas diferentes tareas. Y lo que me gustaría hacer es bajar aquí a este panel de abajo hacia arriba, porque lo que esto nos permite hacer es ver rápidamente, bueno, basado en este tiempo propio, este es el lugar donde se está gastando la mayor parte del tiempo mientras estamos renderizando. Así que tienes tiempo total y tiempo propio. El tiempo total es, digamos, tu método termina llamando en una pila de llamadas a algún otro componente. Eso toma mucho tiempo. Así que el tiempo total en ese nivel superior incluirá todo el tiempo de los métodos hijos. Pero eso no es tan útil, porque el tiempo no se gasta en ese nivel superior. Quieres saber dónde está la función que realmente está tomando todo este tiempo.

Y lo que podemos ver aquí es que en realidad es este parseHtml que está ocupando alrededor del 34% de nuestros tiempos de renderizado. Y ahora podemos comenzar a profundizar en esto. Tal vez lo haga un poco más grande para ti. Y podemos profundizar y decir, bueno, viene de set en el HTML, que está dentro de nuestro componente de celda. Así que ahora eso nos da una forma de poder decir, bueno, en realidad, está bien, puedo ir y verificar y ver, bueno, ¿cuál es el código que está causando que esto suceda? Porque la otra forma en que puedes ver esto es si haces zoom hasta aquí, acercas, acercas, obtienes los nombres de los métodos de lo que se está llamando. Y luego son todas estas pequeñas cajas azules al final es el parseHtml. Así que puedes ver si podemos acelerar esos, vamos a acelerar todo. Y eso es exactamente lo que pudimos hacer.

Si cargo otro perfil. Oh, eso es guardarlo. Lo siento. Este. Así que después del cambio, y te mostraré el código que realmente cambiamos, puedes ver que las cosas realmente han mejorado. Y hemos perdido ese método de este gráfico. Así que podemos ver, está bien, hemos hecho un buen trabajo. Hemos logrado identificar cuál es la parte más lenta, y logramos deshacernos de ella. Y este fue el cambio de código. Simplemente cambiamos de establecer algo de innerHTML a text content. Porque cuando no estábamos en React, estábamos gestionando estas cosas nosotros mismos. Así que innerHTML, solo para un poco de contexto, puede aceptar una cadena que contiene elementos HTML en ella. Así que hay una sobrecarga adicional aquí de verificar qué es esa cadena, emparejar cosas y decir, ¿necesito analizarla y convertirla en algunos elementos DOM? Así que si solo estás estableciendo texto en sí mismo, es mucho más rápido usar text content, porque el navegador es como, bueno, esto es solo una cadena, solo voy a mostrarla. Y al hacer eso, obtuvimos algunas mejoras masivas de rendimiento dentro de la cuadrícula.

Otra cosa, que supongo es otra área de rendimiento que podrías estar interesado en depurar, es si ves estas grandes barras moradas en tu perfil de rendimiento. Así que esta se llama recalculando estilos. Y así, solo la barra estando allí está bastante desconectada de lo que realmente causó que el navegador tuviera que recalcular. Así que no obtienes esta gran flecha azul. Esto es solo yo tratando de hacer posible que lo veas, porque está aquí. Pero es muy delgada. Pero lo que hará es dibujar una flecha de regreso al código, que ha cambiado el DOM de tal manera o ha hecho una solicitud para como una altura de contenedor, que luego ha forzado al navegador a tener que redibujar todos los diseños.

Como ejemplo, donde tuvimos este problema en nuestra cuadrícula, se añadieron nuevas filas al viewport mientras cambiábamos el orden, teníamos algunas animaciones. Así que las filas estaban siendo animadas hacia afuera. Y ahora, para hacer eso de una manera agradable, estábamos añadiendo filas, destruyendo filas, y luego la animación consultaría la altura del contenedor para que pudiera animar estas filas justo fuera de la pantalla. Porque no quieres que salgan volando demasiado rápido. Quieres una especie de velocidad consistente con la que, supongo, se animan hacia afuera. Pero el problema es que estábamos preguntando cuál era la altura del viewport después de haber cambiado la estructura del DOM. Así que porque habíamos cambiado la estructura del DOM, el navegador dice, bueno, no sé qué has cambiado. Necesito forzar el layout para poder darte un valor preciso. Así que los cambios en uno y uno estaban realmente invalidando el valor de la altura. Así que cuando lo leíamos en tres, el navegador se veía obligado a recalcular estilos. Así que la solución para este caso de uso particular fue que añadiríamos nuevas filas. Las filas antiguas fueron destruidas y configuramos la animación. Pero de manera crítica, usaríamos un valor en caché de la altura del contenedor. Porque no es crítico que supiéramos exactamente al píxel para qué era la altura del contenedor. Así que al tomar este valor aproximado, no tenemos que forzar al navegador a reestructurar todo. Y aún estamos obteniendo el mismo efecto sin forzar los layouts. Así que esto se trata de layout thrashing, si quieres profundizar más en este tema.

Muy bien, tengo tiempo. Oh, el tiempo no está funcionando.

Consejos rápidos. Así que estas son algunas de las cosas que he aprendido día a día, que podrías encontrar útiles.

¿Alguien usa NX aquí? No muchos. Si usas NX en una configuración de tipo monorepo, puedes darle este NX underscore profile, ejecutar tu comando, y luego puedes subir eso a DevTools nuevamente. Y eso te dará una línea de tiempo de todos tus trabajos. Así que si tienes una cadena de construcción complicada con muchas tareas dependientes, esta es una buena manera de visualizar eso. Y puede decirte, bien, esta es la cosa que quiero necesitar para poder optimizar. Así que digamos aquí, tenemos este largo aquí. Así que eso es solo una tarea de nodo. ¿Podemos realmente profundizar en eso y perfilar eso? Y la respuesta es que puedes. Así que si ejecutas la tarea de nodo directamente con este guion guion inspect break, y le das la tarea que quieres hacer, y luego vas a Chrome, colon slash slash inspect, hay un DevTools dedicado para procesos no aquí. Así que este es un ejemplo de lo que hacemos aquí. Así que voy a iniciar la tarea con este punto de interrupción de inspección. Voy a mi Chrome en esa URL, y puedo abrir los DevTools dedicados. Así que obtendré un punto de interrupción aquí donde está esperando por mí, puedo ir al panel de rendimiento, comenzar a grabar. Y luego he presionado F8 para que la tarea pueda continuar. Volveré a mi IDE. Así que la tarea está hecha aquí. Volvamos, detengamos el perfil de rendimiento. Y luego podemos usar las mismas técnicas y habilidades que hemos aprendido previamente para ahora perfilar esta tarea de nodo. Y así puedo profundizar y ver, bien, ¿dónde está en esta tarea que necesito mejorar? Y luego, una vez que tienes un rendimiento rápido, podrías querer seguir validando que no lo rompes. Así que hay pruebas de benchmark que puedes hacer en VTest. Y también estoy interesado en la charla más tarde diciendo, ya sabes, ¿puede la IA ayudar en las pruebas de rendimiento? Así que si también estás interesado en eso, tal vez ve a ver esa charla también. Otra cosa es que es posible perfilar el rendimiento o tener pruebas de benchmark para tus tipos de TypeScript. Así que esto es algo que hice para 8igrid también. Teníamos un tipo recursivo complicado para que si nos dices qué forma tiene tu fila de datos, podamos decirte todos los posibles nombres de campo. Y algunos de estos nombres de campo pueden estar anidados con puntos para que puedas profundizar en estos objetos profundos. Y así es realmente agradable dar autocompletado para todo eso.

Pero eso puede ser un tipo costoso. Así que usé esta biblioteca, ArctypeTest y configuré una prueba. Y me dice cuántas instancias se realizaron al hacer esto. Entonces, quiero decir, tal vez eso no sea algo de lo que todos debamos preocuparnos, pero es bueno saber que estas herramientas existen. Y también, si no estás familiarizado con el sitio web.dev, esto es solo un tesoro de artículos e información. Así que si quieres aprender más sobre estas cosas, ve a esta URL y comienza a leer. Esto es del equipo de Chrome, equipo de Google, y hay mucha buena información allí. Y finalmente, todavía tenemos a nuestro buen amigo, console.log, para cuando quieras probar algo un poco más simple.

Muchas gracias. **Amy Henshaw** Cuéntanos un poco sobre tu proceso para verificar problemas de rendimiento, especialmente en un espacio tan voluminoso como grids y charts. ¿Lo haces diariamente? ¿Uno por sprint? ¿Solo cuando es necesario? ¿Cuál es tu proceso? **David Wilson** Entonces, creo que esto es algo que, para nosotros, supongo que tenemos los lanzamientos. Así que un momento regular para repetir estas pruebas de rendimiento es cuando estamos lanzando una nueva versión. Y esto es algo donde las pruebas de benchmark realmente destacan. Así que tenemos esto configurado para nuestra biblioteca de gráficos, donde tenemos algunos ejemplos que cargan miles y miles de puntos en estos gráficos, y ejecutamos este conjunto de métricas de rendimiento para que podamos decir, de acuerdo, esto es lo que era en una versión, y esto es la siguiente versión. Así que eso es como una línea de tiempo agradable para poder...

**Amy Henshaw** ¿Automatizas eso, o alguien se encarga de hacerlo cada vez? **David Wilson** Para eso, alguien se encarga de ello. La prueba de perfilado de benchmark es algo muy complicado, porque hay factores en términos de, bueno, ¿en qué caja de CI se estaba ejecutando? ¿Había muchas otras tareas ejecutándose al mismo tiempo, lo que lo ha ralentizado, por lo que parece que hay una regresión de rendimiento, pero en realidad no lo era. Alguien más solo estaba ejecutando una compilación en la misma caja. Así que tienes que tener en cuenta todas estas cosas. **Amy Henshaw** ¿Como un laboratorio, más o menos? **David Wilson** Sí. Necesitas poder controlar. **Amy Henshaw** ¿Hay algún otro tipo de prueba automatizada que hagas para cosas como el rendimiento, o son solo los benchmarks? **David Wilson** Son solo los benchmarks. Pero también, es ese tipo de por qué de vez en cuando volver y hacerlo probablemente un poco más manualmente. Pero creo que esto es algo en lo que todos podemos, supongo, trabajar, mejorar, es que una vez que has hecho estas mejoras, tratar de tener esas pruebas en su lugar es algo bueno. Pero no es algo sencillo como las pruebas o las pruebas unitarias. **Amy Henshaw** Bueno, no estaríamos aquí si fuera fácil, ¿verdad? Hablemos un poco sobre esos tipos de escenarios donde podrías obtener datos no del todo correctos. ¿Cuáles son los errores comunes que la gente comete al perfilar? ¿O cuáles son las ideas erróneas comunes sobre lo que es un perfil correcto? **David Wilson** Así que supongo que quieres intentar perfilar lo más cerca posible de la experiencia del usuario. Así que para React, eso definitivamente no es perfilar contra el modo de desarrollo, o con el modo estricto activado, porque esa doble renderización, hay muchas otras comprobaciones en curso, y eso está ralentizando la aplicación. Así que podrías pensar que estás haciendo peor de lo que era. Así que ahí es donde React tiene esa opción de perfilado. Así que depende de qué herramienta de construcción estés usando sobre cómo habilitar eso. Pero hay instrucciones en el sitio web de React sobre cómo hacer eso. **Amy Henshaw** Ese es un muy buen consejo. El modo de desarrollo es complicado de esa manera. La pestaña de rendimiento, como dijimos, tiene mucha información. Tiene muchos rincones ocultos. Tiene muchas cosas que evolucionan y son mejoradas por el equipo de Chrome o quien sea. Mencionaste web.dev.

¿Tienes algún otro recurso que tengas para aprender más sobre esto, o alguien que tal vez no sea tan bueno en ello podría comenzar? **David Wilson** Así que creo que no hay nada que supere el sumergirse y simplemente mirar e intentar relacionar las cosas con lo que estás haciendo, viendo cómo interactúa, y comenzar a reconocer tal vez cuáles son los nombres. Y aquí es donde hay una contradicción, supongo. Porque si estás perfilando contra un archivo minificado, no puedes ver lo que está pasando. Así que necesitas ejecutar contra el código no minificado para que obtengas un poco más de ese tipo de información donde puedes ver, bueno, en realidad, es definitivamente... **Amy Henshaw** Obtener un terreno. **David Wilson** Sí. Pero en términos de recursos, creo que el equipo de Chrome está haciendo mucho trabajo en este panel de rendimiento en este momento. Así que las notas de lanzamiento que aparecen cuando actualizas tu Chrome, y luego vas a DevTools por primera vez, te dice qué hay de nuevo. A menudo hay un video allí o una publicación en un blog. Y esa es una muy buena manera de aprender sobre estas nuevas cosas. Así que como para todo esto, las nuevas métricas de web vital, hay una publicación que explica cuál es la motivación detrás de eso. Y es que, como decía, hay mucha información aquí que los desarrolladores no pueden acceder fácilmente. Así que ponerlo frente a nosotros, allí, nos da estas métricas con las que podemos trabajar.