¡Arregla componentes de React lentos en segundos! (Nuevo Addon de GitHub Storybook)

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00GitHub acaba de lanzar un complemento muy potente para Storybook que cambia por completo
00:00:05la forma en que probamos el rendimiento de los componentes.
00:00:07Incluye un panel de rendimiento muy detallado con información valiosa como la medición
00:00:12del tiempo de frames, respuesta a entradas, estabilidad del diseño, perfilado de React, presión de memoria
00:00:18y mucho más.
00:00:19En este vídeo, analizaremos de cerca lo que ofrece este complemento.
00:00:23Será muy divertido, así que vamos a ello.
00:00:31Una pregunta rápida antes de empezar.
00:00:32¿Sabes qué es el “shift-left performance testing”?
00:00:35Es un paradigma de desarrollo que dicta que el rendimiento de los componentes de tu aplicación
00:00:40debe probarse al principio del proceso de desarrollo y no como algo secundario.
00:00:45Y esta herramienta está diseñada específicamente para ayudar a los desarrolladores a tomar esas decisiones tempranas,
00:00:50ofreciendo una visión en tiempo real de cómo se comportan tus componentes antes de llegar a producción.
00:00:55El panel de rendimiento de Storybook ofrece una visión de alta fidelidad de cómo interactúan
00:01:00tus componentes con el motor de renderizado del navegador.
00:01:02Rastrea, por ejemplo, el tiempo de los frames para identificar el “jitter”, esos pequeños huecos irregulares
00:01:07entre frames que hacen que las animaciones parezcan entrecortadas.
00:01:10También monitoriza el hilo principal en busca de rotación del DOM y “thrashing”.
00:01:15La rotación del DOM ocurre cuando el código crea, elimina o actualiza elementos innecesariamente en un bucle cerrado,
00:01:20mientras que el “thrashing” sucede cuando el navegador se ve obligado a recalcular el diseño varias veces
00:01:25en un solo frame porque estás leyendo y escribiendo estilos consecutivamente.
00:01:30Y este complemento se adapta a cualquier framework que utilices.
00:01:33Si usas React, puede resaltar métricas como las cascadas de renderizado, que son esos pequeños
00:01:38cambios de estado que accidentalmente activan una ola masiva y lenta de re-renders en toda la app.
00:01:44También rastrea la duración P95, que muestra el peor de los casos para tus usuarios más lentos
00:01:50en lugar de simplemente un promedio.
00:01:52Y si no usas React, el modo universal funciona perfectamente para Vue, Svelte o componentes
00:01:58web.
00:01:59Para obtener los mejores resultados, se recomienda ejecutar este complemento en Chrome o Edge.
00:02:04También tienen un manual en vivo donde podemos ver estas métricas en acción.
00:02:08Por ejemplo, en el caso de la caja animada, podemos rastrear exactamente cuántas mutaciones
00:02:13de estilo en línea ocurren durante una animación.
00:02:16En este caso, todo parece saludable.
00:02:18La tasa y el tiempo de frames se mantienen perfectamente estables, lo que significa que el navegador
00:02:23maneja esas actualizaciones de estilo sin esfuerzo.
00:02:25Sin embargo, el ejemplo de la lista pesada cuenta una historia diferente.
00:02:29Al filtrar esta lista grande, vemos algunas señales de alerta.
00:02:32Primero, el cambio de diseño acumulativo (CLS) salta a un valor muy alto, lo que indica que
00:02:38los elementos saltan significativamente al cargarse, creando una experiencia molesta para el usuario.
00:02:43También vemos un pico en la rotación del DOM, lo que significa que el navegador trabaja horas extras
00:02:49para eliminar y reconstruir una cantidad masiva de nodos a la vez.
00:02:52Esto también resulta en la pérdida de frames, lo que arruina la percepción de velocidad y fluidez
00:02:57de la interfaz.
00:02:58En el ejemplo de sincronización de elementos, cualquier elemento del DOM con el atributo “element timing”
00:03:04se mide para conocer su tiempo exacto de renderizado.
00:03:06Esto es increíblemente útil porque ayuda a identificar el momento preciso en que tu contenido
00:03:11principal o llamada a la acción se vuelve visible, dándote una imagen más precisa del rendimiento
00:03:17percibido en lugar de métricas genéricas de carga de página.
00:03:21Y cuando miramos el ejemplo de renderizado costoso, al hacer clic en el botón de re-renderizado,
00:03:26hace que la duración P95 se dispare.
00:03:29Esto sucede porque el hilo principal está secuestrado por la ejecución pesada de JavaScript,
00:03:34haciendo que la interfaz se sienta muy lenta.
00:03:36También vemos advertencias de jitter de frames aquí, que indican un renderizado inconsistente
00:03:41donde el tiempo entre frames fluctúa salvajemente.
00:03:44Y también hay un tiempo de bloqueo total (TBT) elevado.
00:03:47El TBT es una señal de advertencia importante porque indica que el hilo principal se bloqueó
00:03:52lo suficiente como para evitar que el usuario interactúe con la página, como hacer clic
00:03:57en un botón o hacer scroll.
00:03:58Y vemos un desglose similar en el ejemplo de desperdicio de memoización.
00:04:03Aquí la demo muestra que re-renderizar cada elemento innecesariamente provoca un retraso
00:04:08masivo.
00:04:09Por el contrario, el ejemplo correctamente memoizado muestra cuánto trabajo se ahorra
00:04:15si memoizamos nuestros componentes.
00:04:16Al omitir esos renders redundantes, mantenemos el hilo principal libre y la tasa de frames estable
00:04:21para obtener esos fluidos 60 frames por segundo.
00:04:25En el ejemplo de cascada de renderizado, vemos exactamente qué sucede al usar “set state”
00:04:30dentro de “use layout effect”.
00:04:31Cada incremento activa una cascada porque “use layout effect” se ejecuta de forma síncrona
00:04:37tras todas las mutaciones del DOM, pero antes de que el navegador pueda pintar.
00:04:42Al activar la actualización de estado aquí, obligas a React a reprocesar el árbol de componentes
00:04:47y al navegador a recalcular el diseño por segunda vez antes de que el usuario vea
00:04:52el primer resultado.
00:04:53Esto es malo porque efectivamente duplica el trabajo para cada frame, provocando un retraso
00:04:58de renderizado que hace que incluso interacciones simples se sientan pesadas.
00:05:02Luego está el ejemplo de rotación de estilos que también demuestra una observación crítica.
00:05:07¿Qué sucede cuando mutamos los estilos en línea de 600 nodos diferentes a la vez?
00:05:13Vemos inmediatamente advertencias de estancamiento en la sección de “thrashing”, lo que indica
00:05:18que el navegador se ve forzado a un bucle de reflow.
00:05:21Intenta calcular las posiciones de 600 elementos simultáneamente mientras el JavaScript aún
00:05:26está realizando cambios.
00:05:27Esto conlleva métricas de frames muy poco saludables porque el hilo principal está completamente
00:05:33saturado.
00:05:34Espero que estos ejemplos te muestren cómo usar este complemento de Storybook para identificar
00:05:38cuellos de botella en un entorno mucho más preciso.
00:05:41Claro, puedes usar una herramienta como Lighthouse, pero Lighthouse es una visión general.
00:05:46No te da esa precisión quirúrgica para ver exactamente cómo un componente individual
00:05:51afecta al rendimiento de tu aplicación.
00:05:53Te animo de verdad a descargar este complemento, añadirlo a tu suite de Storybook y simplemente
00:05:58experimentar con él.
00:05:59Hay mucha información valiosa que ganar una vez que ves el panorama completo de cómo
00:06:03operan tus componentes internamente.
00:06:06Ahí lo tienen, amigos, ese es el nuevo complemento del panel de rendimiento de Storybook
00:06:10de GitHub en pocas palabras.
00:06:11¿Qué opinas al respecto?
00:06:13¿Y cómo mides el rendimiento en tu aplicación?
00:06:16Cuéntanoslo en los comentarios de abajo.
00:06:18Y si te gusta este tipo de desgloses técnicos, por favor házmelo saber haciendo clic
00:06:22en el botón de “me gusta” debajo del vídeo y no olvides suscribirte a nuestro canal.
00:06:28Soy Andrés de Better Stack y nos vemos en los próximos vídeos.

Key Takeaway

El nuevo complemento de rendimiento de GitHub para Storybook revoluciona el desarrollo frontend al permitir que los desarrolladores identifiquen y solucionen cuellos de botella técnicos en componentes individuales mucho antes de llegar a producción.

Highlights

GitHub ha lanzado un nuevo complemento de alto rendimiento para Storybook que permite analizar componentes de React y otros frameworks en segundos.

La herramienta promueve el paradigma "shift-left performance testing", integrando las pruebas de rendimiento al inicio del desarrollo.

El panel de control ofrece métricas detalladas sobre el tiempo de frames, estabilidad del diseño, presión de memoria y perfilado de React.

Permite identificar problemas técnicos críticos como la rotación del DOM, el "thrashing" de diseño y las cascadas de renderizado síncronas.

A diferencia de Lighthouse, este addon proporciona una precisión quirúrgica para evaluar componentes individuales en lugar de toda la página.

Incluye soporte para el peor de los casos mediante la métrica P95 y detecta el tiempo de bloqueo total (TBT) que afecta la interactividad.

Timeline

Introducción al nuevo complemento de rendimiento

El vídeo comienza presentando la potente herramienta que GitHub ha lanzado para Storybook, diseñada para transformar la evaluación del rendimiento de los componentes. Este complemento incluye un panel detallado que mide variables críticas como el tiempo de frames, la respuesta a entradas y la estabilidad del diseño. El presentador, Andrés de Better Stack, destaca que la herramienta ofrece información valiosa sobre el perfilado de React y la presión de memoria. Este segmento establece el tono del vídeo, prometiendo una exploración profunda de cómo estas métricas pueden mejorar el flujo de trabajo del desarrollador. Es el punto de partida esencial para entender la magnitud de esta nueva actualización tecnológica.

El paradigma Shift-Left y métricas de renderizado

En esta sección se explica el concepto de "shift-left performance testing", un enfoque que dicta probar el rendimiento al principio del desarrollo en lugar de al final. El panel de Storybook permite una visión de alta fidelidad sobre cómo interactúan los componentes con el motor de renderizado del navegador. Se introducen conceptos técnicos como el "jitter", que causa animaciones entrecortadas, y la rotación del DOM producida por actualizaciones innecesarias. También se analiza el "thrashing", un problema grave donde el navegador recalcula el diseño repetidamente debido a lecturas y escrituras de estilo consecutivas. Comprender estos términos es vital para cualquier desarrollador que busque crear interfaces fluidas y eficientes.

Compatibilidad universal y métricas específicas de React

Andrés destaca que, aunque el vídeo se centra en React, el complemento es universal y funciona perfectamente con Vue, Svelte o Web Components. Para los usuarios de React, la herramienta resalta las cascadas de renderizado, que son cambios de estado accidentales que ralentizan toda la aplicación. Una métrica clave mencionada es la duración P95, que ayuda a visualizar el peor escenario posible para los usuarios con dispositivos más lentos. Se recomienda el uso de navegadores basados en Chromium, como Chrome o Edge, para obtener los resultados más precisos y detallados. Esta versatilidad asegura que el beneficio de la herramienta se extienda a una amplia gama de profesionales del desarrollo web.

Análisis de casos prácticos: Animaciones y Listas Pesadas

A través de un manual en vivo, el presentador muestra ejemplos reales comparando una caja animada saludable frente a una lista pesada con problemas. Mientras que la animación de la caja muestra estabilidad en los frames, la lista pesada revela señales de alerta como un Cambio de Diseño Acumulativo (CLS) muy elevado. Esto indica que los elementos saltan visualmente al cargarse, degradando significativamente la experiencia del usuario final. Además, se observa un pico en la rotación del DOM y pérdida de frames debido a la reconstrucción masiva de nodos. Se menciona el atributo "element timing" como una herramienta increíblemente útil para medir cuándo un contenido principal se vuelve realmente visible.

Bloqueo del hilo principal y optimización con memoización

Esta sección analiza el "renderizado costoso" y cómo el secuestro del hilo principal por JavaScript pesado dispara la duración P95 y el Tiempo de Bloqueo Total (TBT). El TBT es crítico porque indica periodos donde el usuario no puede interactuar con la página, como hacer scroll o clics. El vídeo demuestra visualmente cómo el desperdicio de memoización provoca retrasos masivos al re-renderizar elementos de forma redundante. Por el contrario, se muestra un ejemplo correctamente memoizado que mantiene los 60 frames por segundo estables al liberar el hilo principal. Estos ejemplos prácticos subrayan la importancia de técnicas de optimización básicas pero poderosas en aplicaciones complejas.

Cascadas de renderizado y rotación de estilos

Se explora el impacto negativo de usar "set state" dentro de un "use layout effect", lo que provoca cascadas de renderizado síncronas. Esta práctica obliga a React y al navegador a realizar el doble de trabajo antes de que el usuario pueda ver el primer resultado visual. Otro ejemplo crítico es la mutación de estilos en línea en 600 nodos simultáneamente, lo que satura completamente el hilo principal. El panel de Storybook identifica estos cuellos de botella mediante advertencias de estancamiento y bucles de reflow ineficientes. Estos detalles técnicos permiten a los desarrolladores corregir errores de arquitectura lógica que a menudo pasan desapercibidos en las pruebas manuales estándar.

Conclusión y comparación con Lighthouse

Para finalizar, el vídeo compara este complemento con Lighthouse, señalando que mientras Lighthouse ofrece una visión general, Storybook brinda una precisión quirúrgica sobre componentes individuales. El presentador anima a la audiencia a descargar el complemento y experimentar con él para obtener una visión completa del funcionamiento interno de sus componentes. El análisis concluye reforzando que ver el panorama completo del rendimiento es clave para el éxito a largo plazo de cualquier proyecto. Andrés se despide invitando a los espectadores a compartir sus métodos de medición de rendimiento en los comentarios. El cierre motiva a la comunidad a adoptar mejores prácticas de monitoreo desde las etapas iniciales del ciclo de vida del software.

Community Posts

View all posts