Depuración de Rendimiento Con AI

Trabajo para AG Grid pero no voy a hablar sobre la cuadrícula hoy. Voy a hablar sobre un agujero de conejo en el que desaparecí durante varios meses. Depurar el rendimiento de renderizado es realmente difícil y quería intentar averiguar cómo hacer que la IA haga eso por mí. Y he estado tratando de pensar en qué cubrir porque es solo una charla de siete minutos aquí y lo que creo que tengo tiempo para, no voy a poder guiarte a través de todo el proceso, pero quiero inspirarte con algunas cosas que quizás no te hayas dado cuenta que eran posibles de maneras en que puedes hacer que la IA aborde este problema realmente difícil por ti. Así que, en primer lugar, por qué el rendimiento de renderizado es realmente difícil de depurar.

Básicamente es difícil de depurar porque la información que obtenemos de las herramientas no es muy buena. Así que vamos a grabar un perfil de rendimiento en Chrome aquí. Haces clic en ese pequeño botón, interactúas con tu aplicación y lo detienes y obtendrás esto llamado un gráfico de llamas de rendimiento. Y la cosa que quiero mostrarte en esto, así que en primer lugar es un pequeño video en la parte superior que te muestra tu interacción. Puedes elegir una parte que te interese, hacer zoom en ella y lo que quiero mostrarte es qué tan buena es la información que estás obteniendo para la sección de JavaScript. Te muestra cada función en tu aplicación, exactamente cuánto tiempo dura y esta es la razón por la que los marcos son tan rápidos. Tienen esta información increíble para optimizar ese rendimiento.

Cuando intentas que el rendimiento de tu renderizado sea rápido, no obtienes nada de eso. Solo te dice cuánto tiempo pasaste en cada sección de la aplicación. Y entonces lo que hemos tenido que hacer históricamente si queremos que nuestras aplicaciones se rendericen rápido es básicamente hacer ciencia en nuestras aplicaciones. Así que, en primer lugar, necesitas aprender tanto como puedas sobre el proceso de renderizado y CSS. Luego, básicamente, formulas hipótesis, como razones por las que crees que tu aplicación podría ser lenta y las pruebas editando tu aplicación y grabando otro perfil de rendimiento y observando las diferencias y básicamente es hacer ciencia. Es meticuloso, es repetitivo, consume tiempo y puede ser realmente aburrido. Y si hay algo en lo que la IA es buena, es en automatizar cosas aburridas.

Así que hay una Chrome developer tools MCP, que si instalas, puede hacer cualquier cosa que puedas hacer en esa UI. Puede hacer clic a través de tu página, grabar trazas de rendimiento y analizarlas. Y lo más importante que la IA puede hacer es allanar la curva de aprendizaje. Así que solía ser que necesitabas ser un experto para obtener resultados. Ahora básicamente puedes empezar a hacer esto y conseguir que la IA te lleve a través del proceso y aprendas sobre la marcha. Así que si solo hay dos cosas que te llevas de esto, quiero que sean estas dos cosas.

En primer lugar, para que todo esto funcione, tienes que instalar las Chrome developer tools MCP. Sin eso, Claude no sabe lo que no sabe. No te recomendará que hagas esto. Simplemente será ignorante. Así que necesitas hacer eso tú mismo. Y luego mi gran sugerencia es preguntar a la IA cuáles son tus opciones. No digas arregla este problema de rendimiento. Ni siquiera digas por qué es lento. Di explícame mis opciones. Y así es como te conviertes en un experto. Así es como aprendes y construyes una caja de herramientas de técnicas.

Así que voy a mostrarte algunas de estas técnicas ahora. Nuevamente, solo vamos a repasarlas bastante rápido. Pero la idea es mostrarte lo que es posible. Y solo recuerda, cualquier cosa aquí, puedes hacer que la IA te lo explique y luego hacerlo la próxima semana. Así que la primera es una regresión por sección. Así que una regresión es un caso especial de un problema de rendimiento donde tienes una versión de tu aplicación que sabes que es buena y una versión que sabes que es mala. Y puedes averiguar automáticamente exactamente. Por ejemplo, puedes pedirle a Claude que encuentre el commit que introdujo este problema y hará algo llamado git by section por ti. Así que si sabes que hace 50 commits, tu aplicación estaba bien.

Ahora tiene este problema. Puedes decir, encuentra el commit que lo introdujo, y comprobará un commit en el medio y lo probará. Como en, comprobará ese código fuente, construirá tu aplicación, la abrirá, iniciará el servidor de desarrollo, la abrirá en Chrome, navegará a la página, realizará la acción que le dijiste que era lenta, grabará el perfil de rendimiento, descubrirá si es lenta o no, cosas realmente que consumen mucho tiempo. Y digamos, OK, descubrimos que el commit 25 estaba bien. Así que repetirá el proceso nuevamente, y pasará sistemáticamente por todo tu historial de commits para encontrar el commit exacto. Y me he ido a un descanso para almorzar donde tuve esto haciéndolo durante una hora, y volví, y es como, oye, este commit, ese es tu problema.

Así que otra técnica que uso todo el tiempo es una reproducción independiente. Así que aquí está la página que te mostré antes que grabó una traza de rendimiento. Si estaba interesado en el rendimiento de redimensionamiento de esa cuadrícula, hay un montón de otras cosas ahí arriba que son solo ruido que va a contaminar la traza. Así que puedes decirle a Claude, oye, aquí hay una página que me interesa. Solo haz una versión independiente de eso que solo tenga la cuadrícula. Y le pedí que hiciera eso, y construyó esto. Ahora, si estamos interesados en el rendimiento de redimensionamiento, puedes hacer este pequeño botón aquí donde tienes un pequeño botón que solo redimensiona la cuadrícula cinco veces. Si grabas una traza de rendimiento mientras haces eso, obtendrás datos realmente limpios.

No hay nada más en la página. Así que nuevamente, una gran manera de investigar tus problemas de rendimiento. Hay una prueba de estrés sintética, otra técnica que uso todo el tiempo. Así que la idea básica aquí es que si piensas que algo podría ser un pequeño problema, crea un ejemplo loco que lo haga un gran problema para que puedas verlo. Así que recibimos informes de que cuantos más elementos había en una página, más tiempo tardaban nuestros estilos en cargarse. No podíamos verlo suceder normalmente. Así que simplemente dije, Claude, construye una página que tenga 100,000 divs en ella.