Optimización de animaciones con Performance DevTools

Clase 18 de 22 • Curso de Debugging con Chrome DevTools

Resumen

Medir y optimizar el performance con DevTools es clave para ofrecer una experiencia fluida, incluso en equipos de gama baja. Aquí verás cómo usar la pestaña Performance, leer su reporte sin perderte y atacar cuellos de botella en animaciones con JavaScript, FPS y CPU bajo control.

¿Por qué medir el performance con DevTools?

La experiencia del usuario depende de que la página cargue rápido y responda sin saltos ni bloqueos. Por eso, además de probar en dispositivos reales de gama baja o media, conviene analizar con DevTools para encontrar problemas antes de que los sufran tus usuarios.

¿Qué señales indican mala experiencia de usuario?

Carga lenta desde el inicio.
Scroll e interacciones con saltos en la animación.
Botones que no responden aunque “ya cargó”.

¿Por qué simular un CPU lento?

No todos los usuarios tienen equipos potentes.
Reducir CPU (por ejemplo, 4x más lento) expone problemas reales.
Un warning avisa del cambio en el poder de cómputo del navegador.
Añadir muchos elementos estresa la animación y revela cuellos de botella.

¿Cuándo empezar a medir en Performance?

Abre la pestaña Performance y presiona Grabar.
Como en Network, no verás datos hasta iniciar la grabación.
El refresco automático captura peticiones, tiempos y pesos para generar el reporte.

¿Cómo grabar y leer el reporte en la pestaña performance?

Al grabar unos segundos verás un reporte con mucha información. Enfócate primero en señales claras: línea roja, FPS, CPU y el sumario en forma de dona. Así localizarás las causas principales de lentitud.

¿Qué significa la línea roja y el FPS bajo?

La línea roja indica sobrecarga de JavaScript y frames que tardan más de lo debido.
Un FPS bajo (por ejemplo, 6) contrasta con la buena práctica de 60 FPS.
Más tiempo por frame implica animaciones lentas y mala experiencia.

¿Cómo interpretar CPU y el sumario en dona?

La barra de CPU al límite revela saturación de cómputo.
La dona resume tiempos por tipo: amarillo para scripts, púrpura para render, verde para paint, además de sistema e idle.
El mayor consumo está en render (púrpura) y scripts (amarillo): cuellos de botella prioritarios.
El paint es rápido; el idle muestra pausas breves (milisegundos), como se espera.

¿Para qué sirven frames y screenshots?

Cada screenshot representa un frame de la animación.
Con hover puedes ver qué elementos cambian en cada frame.
Al abrir un frame en summary, navega con flechas para analizar la animación y detectar dónde no carga algo.

¿Dónde encontrar cuellos de botella en main y cómo arreglarlos?

La pista más útil está en la pista de main: cada rectángulo es una tarea. Las barras largas delatan tareas costosas; un triangulito rojo marca un warning. Al hacer clic verás la información y podrás saltar a source en la línea exacta que tarda más.

¿Cómo identificar tareas costosas y el código involucrado?

Acerca el timeline de main para ver secuencias: animación disparada, función que la inicia y actualizaciones.
Tareas breves: decenas de milisegundos (p. ej., 68 ms).
Tarea problemática: alrededor de 139.56 ms y con warning.
Haz clic en el warning para abrir source en la línea específica.
Las líneas amarillas indican ejecución lenta: foco de optimización.

¿Qué pasos seguir para debuguear y optimizar?

Graba en Performance con CPU limitado y alta carga visual.
Confirma señales: línea roja y FPS bajo.
Usa la dona para priorizar: render y scripts primero.
En main, localiza tasks largas y abre source desde el warning.
Coloca breakpoints y debuguea el JavaScript para reducir el tiempo de esas tareas.
Itera hasta que la animación sea suave con la misma carga y CPU lento.

¿Cómo validar la mejora?

Alterna entre optimizar y desoptimizAR para comparar la animación.
Repite la grabación: busca más FPS y menor presión en CPU.
Verifica que desaparezcan warnings y que los rectángulos largos se acorten.

¿Tienes dudas sobre la lectura del timeline o el uso de breakpoints para mejorar la animación? Comparte tu caso y comentamos soluciones puntuales.

Alejo Vera

student•

Sad, mi computadora sin throttling ya funcionaba como la del profe con throttling

Ruben Alvarez A

student•

es por que estas viendo el video tamb, pon pause al video y haz el ejercicio.

Juan Christopher

student•

Lol... Que mal xD

Jhean Pacheco

student•

Conclusión sobre el reto Bueno según lo que he podido investigar (corregidme si estoy equivocado) es que el problema esta en la forma en que obtiene una nueva posición para el elemento.

Algoritmo no optimizado

var pos = m.classList.contains('down') ? m.offsetTop + distance : m.offsetTop - distance;

Aquí podemos observar que obtiene la posición del elemento con respecto al contenedor más cercano en posición relativa (en este caso body) y esto lo hace para cada iteración y cada elemento teniendo que cada vez volver a consultar esa posición para generar una nueva.

Algoritmo optimizado

var pos = parseInt(m.style.top.slice(0, m.style.top.indexOf('px')));
m.classList.contains('down') ? pos += distance : pos -= distance;

Aquí para obtener la posición lee el estilo top anterior del elemento y a partir de ese genera una nueva posición.

La diferencia es que el primer algoritmo (offsetTop) consume mucho más recursos ya que debe consultar del DOM en cada iteración (es una nueva operación para cada elemento y cada iteración), mientras que con el segundo algoritmo (style.top) solamente consulta la posición anterior del estilo almacenado (no debe hacer una nueva operación).

Si estoy equivocado por favor corregidme.

Carlos Eduardo Gomez García

teacher•

Dude! Estaba buscando a alguien que confirmara mi teoría, acabé deduciendo lo mismo que tu, y efectivamente estamos en lo correcto, offsetTop hace que el navegador tenga que ir a calcular el valor de dicha propiedad, con style.top simplemente lee una propiedad ya almacenada

Jhean Pacheco

student•

Gracias por confirmar!

Edgar Oswaldo Vargas Jara

student•

Mi PC anda como una calculadora Casio

Victor Andres Castillo Zambrano

student•

jejejejeje

sergio osvin mazon guzman

student•

Tú le tienes que dar stop, si no se sigue y se sigue jaja

Diego Rodriguez

student•

que curso tan genial

Jimmy Buriticá Londoño

student•

Es cierto, estamos aprendiendo mucho.

Juan Christopher

student•

Si... Es muy interesante.

Carlos Eduardo Gomez García

teacher•

Vale, en cuanto al reto creo que logré encontrar por qué no está optimizado. Independientemente de que se está llamando a la propiedad "offsetTop" dentro de un if en varias ocaciones (Esto no es buena práctica, pues por cada vez que se llama, el navegador tiene que ir a recalcular el valor de esa propiedad, lo mejor es guardar su valor en una variable), esta propiedad parece tener un problema de performance, porque incluso, si al código optimizado, le pones esa propiedad, la animación seguirá lenta, en cambio, si obtienes el valor directamente de los estilos es cuando se logra optimizar 🤔

Rubén Ernesto Aragón Gil

student•

Gracias, profe.

Juan Esteban Galvis

student•

Creo que lo solucione, en la línea 65 (Dado que la línea que marca el Performace es la 95 que llama a la función app.update en la línea 62)

Hay un condicional que dice: if (!app.optimize) y en la línea 32: optimize = false; al borrar el negar (!) se optimiza. profesor estoy en lo correcto?

Beatriz Pérez Santana

student•

Hola @JuanGalvis, como tú dices, si le quitas la negación a la condición se optimiza porque por defecto esta expresión app.optimize tiene como valor false. Este valor se cambia cada vez que haces click en el botón “Optimize” al igual que su texto, pasando de “Optimize” a “Un-Optimize”.

Entonces al cambiar la condición, por defecto estás entrando en el código de la condición que está optimizado.

Y esto te llevaría a un error visual en cuanto al texto del botón porque si tu cambias la condición y le das click al botón aunque éste diga “Optimize” no optimizaría el código sino todo lo contrario.

👀Observando un poco más el código con las herramientas del navegador, creo que el error se encuentra en la línea 71.

Se puede observar que debajo de la función app.update se están están ejecutando otras cosas. Recalculate Style y Layout ambas con un triángulo rojo indicando que podemos estar haciendo algo mal en el código. Le hago click a “Recalculate Style” y aparece:

Un warning ⚠️que dice: Forced reflow is a likely performance bottleneck
Recalculation forced – app.js:71
First invalidated – app.js:70

Pero, ¿qué es Recalculate Style y Layout? 🤔

Para mostrar un frame en la pantalla el navegador sigue una serie de pasos:

Recalculate Style: El paso de combinar el DOM y el CSSOM obteniendo así el Render Tree.
Layout (o también llamado ++Reflow++): El paso que hace el navegador para averiguar el tamaño y las posiciones de los elementos en la página.

A veces se puede forzar al navegador a realizar el layout de manera anticipada con JavaScript. A esto se le denomina Forced synchronous layout. Y eso es lo que le está pasando a este código.

En la línea 70:

m.style.top = pos + 'px';

En JavaScript se está cambiando el estilo de la imagen, en este caso la posición top.

En la línea 71:

if (m.offsetTop === 0) {

Con m.offsetTop se está pidiendo conocer el valor de esa propiedad del elemento para poder hacer la comparación.

Si en la línea anterior (70) no se hace el cambio de estilo no habría problema porque se leería el valor del frame anterior pero al cambiar el estilo, el cambio hace que el navegador invalide ❌ todo lo que tenía registrado y deba actualizar ✅ los estilos (Recalculate style) y por lo tanto, ejecutar el layout para poder devolver el offsetTop correcto.

En otras palabras, esto lo hace porque al cambiar el estilo de la imagen y luego preguntar cual es la posición de la imagen el navegador no sabe si la posición ha cambiado y decide volver a ejecutar el paso de layout para poder obtener su posición.

Y como está en un ciclo 🔄, estás operaciones se están continuamente repitiendo. De ahí el warning: “Forced reflow is a likely performance bottleneck”.

Para evitar esto se recomienda:

1️⃣Primero ++leer++ los estilos (ejemplo de leer: element.width)
2️⃣Y luego ++escribirlos++ (ejemplo de escribir: element.width = '100px')

En la solución del código optimizado lo que hacen es añadir a la variable pos la posición de la imagen y es esta variable la que utilizan en la condición. Lo que consiguen con esto es:

Que el navegador no tenga que estar averiguando en varias líneas del código que posición tiene la imagen.
Que no se fuerce el Layout ya que en la línea anterior a la condición se sigue cambiando el estilo de la imagen.

Y si haces trabajar menos al navegador, el rendimiento de la página mejorará 💪.

En el enlace que puso el profesor también se menciona que el código se podría optimizar aún más si se utilizaran propiedades (transform y opacity) que sólo afecten al último paso (Composite).

En general, con lo que me quedo es que las propiedades que cambiamos o leemos en JavaScript y dónde lo hacemos afectan al rendimiento 😅.

Enlaces recomendados:

El que puso el profesor
Y este que habla en profundidad sobre el layout

Mayk Edison Perez Arzapalo

student•

Buen análisis @beaps, toma tu like!

Marcelo Veron

student•

lo que hice fue desactivar el optimizar en la linea 65 le quite el ! jajaj xd solucionado quedo if (!app.optimize)
if (app.optimize)

Ruben Alvarez A

student•

lo que hiciste fue entrar a ese if, eliminaste un distinto(!) entonces accede a la funcion del boton optimizar

Sergio Maximiliano Salvatierra

student•

Solución al reto:

En cada iteracion, dentro de los if se trae el valor que esta dentro m que es un objeto para compararlo. Seria mas rapido trabajar con un valor que no este dentro de un objeto, pos:

var pos = parseInt(m.style.top.slice(0, m.style.top.indexOf('px')));
m.classList.contains('down') ? pos += distance : pos -= distance;

m.style.top es un string que contiene el numero+px por eso es neceario guardarlo sin el px y pasarlo a un numero entero. Y se le suma o resta distance dependiendo de si esta subiendo o bajando.

Camilo Gonzalez

student•

Si ya no esta disponible: https://web.archive.org/web/20200721205417/https://googlechrome.github.io/devtools-samples/jank/

Con dev tools le quitan el ancabezado para que no estorbe, usando display:none

Para cuando ya no esta disponible un recurso, pueden usar https://web.archive.org/ para encontrar versiones guardadas de sitios caidos.

CRISTIAN BARBERO PÉREZ

student•

La solución que he encontrado es eliminar el if de la línea 65 de tal manera que se ejecute siempre el else:

var pos = parseInt(m.style.top.slice(0, m.style.top.indexOf('px')));
        m.classList.contains('down') ? pos += distance : pos -= distance;
        if (pos < 0) pos = 0;
        if (pos > maxHeight) pos = maxHeight;
        m.style.top = pos + 'px';
        if (pos === 0) {
          m.classList.remove('up');
          m.classList.add('down');
        }
        if (pos === maxHeight) {
          m.classList.remove('down');
          m.classList.add('up');
        }

Yosef Enmanuel Blandin Rios

student•

Mi Intel Core 2 Duo sufrio mucho jajaja

Kevin Jefferson Lopez De la O

student•

Recuerden: Es una buena practica generar 60 fps (frame por segundo)

Derek Samuel Paúl Peña

student•

TIP: Revisen la función que se lanza al hacer click en el botón de optimize.

Enrique Rabell Talamantes

student•

No me sale lo azul del uso del cpu alguien sabe porque podria ser?

Massimo Di Berardino

student•

Hola Enrique, debes darle check a la cajita de memory en la parte superior del DevTools

Joseph Humberto Cueva

student•

Al darle click al enlace app.js:95 no me muestra el archivo javascript

Kelvin Araque

student•

estas en linux ?

Markin Piero Pulache Guarniz

student•

tampoco me aparece

Santiago Andres Alvarez Cuadros

student•

En realidad, a lo que hace referencia Idle es el tiempo muerto, donde ya la página terminó de realizar todos los pasos anteriores. Una página bien optimizada tendrá un Idle mucho más grande en relación a los otros parámetros en la pestaña de Summary. Lo he probado en varias páginas, y he visto que puede ser hasta más de un 95% mayor que el resto de los parámetros.

FELIX EVR

student•

18. ¿Cuándo utilizar la sección de Performance?

11:46 Reto de la clase.

Enlaces de la clase: Get Started With Analyzing Runtime Performance Enlaces complementarios: Tutorial ¡Aprende a optimizar tus sitios web! - Resolviendo el reto de la clase de optimización de RetaxMaster Comentarios valiosos de la comunidad: 1

Kelvin Araque

student•

para poder solucionar el reto de la optimaizacion de condigo vamos a la línea 66 sustituimos la propiedad offsetTop debido a que esta crea una gran carga de js por cada elemento calculado en el viewport y debemos reemplazar estos por css en js osea empezar a usar cssom

/*
• El método slice() devuelve una copia de una parte del array dentro de un nuevo array 
empezando por inicio hasta fin

• El método indexOf() retorna el primer índice en el que se puede encontrar un elemento dado en el array

recordemos también  que las pantallas  cargan desde arriba hacia abajo

⬇️ 0px, origen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
|                                                                |
|                                                                |
|                                                                |
|                                                                |
|                                                                |
|                                                                |
|                                                                |
|                            maxHeight    ⬇️        |
|_ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _|    
                                                                      
*/

var posicionElement = parseInt(m.style.top.slice(0 ,m.style.top.indexOf('px')));

m.classList.contains('down') ? posicionElement  += distance : posicionElement -= distance ;

if(posicionElement < 0)
{
  posicionElement = 0;
}
if(posicionElement  > maxHeight)
{
  posicionElement = maxHeight;
}

m.style.top = posicionElement + 'px';

if (posicionElement === 0)
{
  m.classList.remove('up');
  m.classList.add('down');
}
if (posicionElement === maxHeight)
{
  m.classList.remove('down');
  m.classList.add('up');
}

desde aquí pueden descargar el repo para hacer las pruebas offline

https://github.com/GoogleChrome/devtools-samples

DAVID EDUARDO BAEZ SANCHEZ

student•

A seguir aprendiendo.

Cristian Leonardo Cárdenas Garcia

student•

Excelente Clase, mucho por aprender

Optimización de animaciones con Performance DevTools

Introducción

Debugging con Dev Tools: curso intermedio

Qué son las Chrome Dev Tools y cómo abrirlas

Elementos y Estilos

Manipular HTML con DevTools Elements

Chrome DevTools: editar CSS en tiempo real

Selector de colores DevTools en Chrome

Generar sombras CSS con Chrome DevTools

Animaciones CSS con Dev Tools: timing y velocidad

Midiendo código no utilizado con DevTools Coverage

JavaScript con DOM en Dev Tools

Cómo guardar cambios de DevTools en archivos locales

Mobile Simulation

DevTools para proyectos responsive

DevTools simula red lenta y CPU débil para probar

JavaScript

Cómo debuguear JavaScript con DevTools

Debuggear concatenación con DevTools

Network

Proyecto de Clase Disponible en Platzi

Network en DevTools: qué se descarga y pesa

Cómo usar Network para depurar peticiones HTTP

Performance