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.