El panel de animaciones: capturar e inspeccionar

Hay una herramienta en las DevTools que responde en diez segundos preguntas que de otro modo cuestan media hora de leer código: qué se está animando exactamente, cuánto dura de verdad, en qué orden arranca cada parte y qué elemento corresponde a cada barra. Casi nadie la usa, en parte porque está escondida en el cajón y en parte porque su modelo de captura no es evidente hasta que alguien te lo explica.

Abrir y capturar

En Chromium, el panel vive en el cajón inferior: pulsa Escape para abrirlo y elige la pestaña Animations; si no está, aparece en el menú de tres puntos del cajón, en More tools. En Firefox está integrado en el inspector como una pestaña lateral junto a Reglas y Diseño.

El modelo de captura es lo que hay que entender primero, porque produce el desconcierto inicial de todo el mundo: el panel solo registra animaciones que empiezan mientras está abierto. Si abres el panel después de disparar la animación, no verás nada. El flujo correcto es abrir el panel, dejar la página quieta, y entonces provocar la interacción.

Lo segundo es la agrupación. El panel no lista animaciones sueltas: agrupa en un mismo bloque todas las que arrancan dentro de una ventana temporal corta. Un modal que abre a la vez el fondo, el diálogo y tres elementos escalonados aparece como un solo grupo con cinco filas, y esa agrupación es justamente lo que te deja ver la coreografía completa de un vistazo. La lista de la izquierda acumula un grupo por cada disparo; el botón de borrar los limpia todos.

Qué se ve en un grupo

Al seleccionar un grupo, la parte derecha muestra una línea de tiempo con una fila por animación.

El nombre. Para una animación CSS, el nombre de los @keyframes. Para una transición, la propiedad que transiciona. Para una animación creada con element.animate(), el identificador que le hayas dado, o uno genérico si no le pusiste ninguno. Ponerle nombre a tus animaciones de WAAPI merece la pena solo por esto:

elemento.animate(keyframes, { duration: 320, easing: "ease-out", id: "entrada-tarjeta" });

El tramo de retardo. Un segmento atenuado al principio de la barra, que representa el delay. Ver los retardos alineados unos junto a otros es la forma más rápida de entender un escalonado y de detectar el que se te fue de las manos.

El tramo activo. La parte sólida: la duración real. Aquí es donde se descubren la mitad de los problemas de coreografía, porque lo que uno cree que dura trescientos milisegundos a menudo dura ochocientos.

Los círculos de keyframe. En las animaciones CSS con @keyframes de varios pasos, cada porcentaje aparece como un punto en la barra. Su posición muestra el reparto temporal real, que no siempre es el que uno recuerda haber escrito.

Las iteraciones. Una animación repetida dibuja su tramo activo tantas veces como iteraciones tenga. Una infinita se dibuja hasta el borde.

Y dos gestos que valen mucho: pasar el ratón por una fila resalta el elemento en la página con el mismo recuadro que usa el inspector, y pinchar en el nombre lo selecciona en el panel de elementos. En una coreografía de doce filas, eso responde “¿cuál de estas es la que se ve mal?” sin leer una línea de CSS.

Qué aparece y qué no

Esta es la parte que ahorra frustración, porque el panel no es un observador universal.

Aparece:

• Las transiciones CSS.
• Las animaciones CSS con @keyframes.
• Las animaciones creadas con element.animate() y con la API de WAAPI en general.
• Por extensión, todo lo que crea una librería que delegue en WAAPI, que incluye buena parte de lo que hace una librería híbrida moderna.
• Las animaciones dirigidas por scroll, en los navegadores que las implementan, con su propio indicador de progreso en lugar de una línea de tiempo temporal.

No aparece:

• Nada dirigido por requestAnimationFrame que escriba estilos en línea. Esto incluye la parte del motor de GSAP que no delega, los muelles interrumpibles de cualquier librería, y tu propio bucle.
• Los cambios de estilo aplicados de golpe sin transición.
• El movimiento de un canvas, un vídeo o un contexto WebGL.
• Las animaciones dentro de un iframe de otro origen.

Ese primer punto tiene un uso diagnóstico que es la mejor razón para conocer el panel: si el elemento se mueve y el panel no muestra nada, sabes con certeza que hay un bucle de JavaScript escribiendo estilos. Y eso te dice de inmediato que la animación no está en el compositor y que se va a congelar en cuanto el hilo principal se ocupe. Es la misma conclusión a la que llegarías bloqueando el hilo, pero sin escribir nada.

Las cuatro preguntas de diez segundos

¿Cuánto dura de verdad esto? Dispara la interacción con el panel abierto y lee el ancho del grupo completo. Una apertura de modal que “es instantánea” y ocupa novecientos milisegundos de línea de tiempo es un descubrimiento habitual, y casi siempre el culpable es un retardo heredado o una transición sobre una propiedad que nadie recordaba.

¿Qué se está animando además de lo que yo creo? El número de filas del grupo. Cuando salen doce y tú escribiste tres, las nueve restantes vienen de una regla transition: all, del sistema de diseño, o de un componente hijo. Esas nueve están costando trabajo en cada apertura.

¿Por qué esto se siente descoordinado? Mira la alineación de los tramos de retardo. Una coreografía que se percibe torpe casi siempre tiene dos elementos que deberían empezar juntos y empiezan con cuarenta milisegundos de diferencia, o un elemento largo que termina mucho después que el resto y deja la sensación de que la transición “no acaba”.

¿Qué elemento es esta barra? Pasa el ratón. Es trivial y es la razón principal por la que el panel merece estar abierto durante cualquier trabajo de coreografía.