El presupuesto de un fotograma y qué cabe dentro

La cifra de dieciséis milisegundos y medio se repite tanto que ha dejado de significar algo. No es el presupuesto que tienes: es el intervalo entre dos refrescos de un panel de sesenta hercios, del cual el navegador necesita una parte para su propio trabajo, y del cual una fracción creciente de tus usuarios ni siquiera dispone porque su pantalla va al doble. Poner números correctos a esto cambia qué decisiones parecen razonables.

Los números de verdad

El intervalo entre refrescos sale de dividir mil entre los hercios del panel:

La tercera columna es la que importa y la que casi nunca se cita. El intervalo no es tuyo entero. El navegador necesita una parte de cada ciclo para su propio trabajo: recoger la entrada, hacer el commit, coordinar el rasterizado, componer y presentar. La recomendación clásica de las guías de rendimiento —dejar unos diez milisegundos de los dieciséis para tu trabajo— es exactamente eso: un margen de un tercio para la maquinaria.

Y a sesenta hercios, esos diez milisegundos tienen que cubrir todo lo que va del hilo principal: tus manejadores de entrada, tus devoluciones de fotograma, el recálculo de estilo, el layout, la pintura y el commit. No es mucho.

A ciento veinte hercios, que es la frecuencia de una parte creciente de los móviles de gama alta y de los portátiles recientes, el presupuesto útil baja a unos cinco milisegundos. Es la mitad de trabajo por fotograma con la misma cantidad de píxeles que producir.

El precipicio

Aquí está la propiedad que hace que el rendimiento de animación se comporte de forma tan poco intuitiva: el coste de pasarse no es proporcional, es cuantizado.

Si tu fotograma tarda 15 milisegundos a sesenta hercios, llegas. Si tarda 17, no llegas por dos milisegundos y el resultado no es un retraso de dos milisegundos: es que ese fotograma se pierde y el siguiente refresco muestra el anterior. La latencia real pasa de 16,7 a 33,3 milisegundos. Dos milisegundos de exceso han costado dieciséis y medio de latencia percibida.

Esa discontinuidad tiene dos consecuencias prácticas.

La primera: no hay grados de “casi va bien”. Una animación a 60 fotogramas por segundo y una a 58 no se diferencian en un 3%: la segunda tiene dos tirones por segundo, y el ojo humano los detecta con una facilidad notable, porque lo que se percibe no es la media sino la irregularidad.

La segunda: la optimización que baja de 17 a 15 milisegundos vale muchísimo más que la que baja de 30 a 25. La primera cruza el umbral y duplica la fluidez percibida; la segunda mejora un caso que ya estaba perdido. Cuando priorizas trabajo de rendimiento de renderizado, mira dónde están los umbrales, no los porcentajes.

Hay un matiz que suaviza la primera consecuencia en los dispositivos modernos: muchos paneles tienen frecuencia variable, y el sistema puede bajar de 120 a 60 hercios de forma coherente en lugar de perder fotogramas sueltos. Una animación que sostiene 60 constantes en un panel de 120 se ve bien; una que oscila entre 90 y 50 se ve fatal aunque su media sea mejor. La constancia importa más que el número.

Qué cabe dentro

Un reparto defendible para un fotograma de sesenta hercios, con los diez milisegundos útiles:

Y lo que eso significa en términos concretos, que es lo útil:

Cabe: actualizar el estilo de unas decenas de elementos, calcular el layout de un subárbol acotado, ejecutar una devolución de fotograma que haga aritmética sobre unos cientos de valores, animar posiciones de una lista corta.

No cabe: volver a renderizar un árbol de componentes de mil nodos, recalcular el estilo del documento entero, hacer layout de una lista de cinco mil filas, parsear una respuesta de red de tamaño medio, ordenar diez mil objetos.

Y hay una tercera categoría que es la más importante: lo que no consume presupuesto en absoluto. Una animación de transform u opacity gestionada por el motor no toca el hilo principal, así que su presupuesto no es de diez milisegundos: es de cero. Esa es la razón de que la estrategia correcta ante un problema de fluidez casi nunca sea optimizar el trabajo del fotograma, sino sacar la animación del hilo principal para que no haya trabajo de fotograma.

Dicho de otra forma: el presupuesto de fotograma es una herramienta para razonar sobre lo que tiene que ocurrir en el hilo principal. Todo lo que se pueda sacar de ahí no compite por él.

Medir el presupuesto real del dispositivo

Dos mediciones, y las dos hay que hacerlas en el dispositivo de referencia y no en el de desarrollo.

La frecuencia de refresco real, que no es una constante y que en muchos dispositivos depende del estado de la batería y del modo de ahorro:

async function frecuenciaDePanel(muestras = 90) {
  const marcas = [];
  await new Promise((resolver) => {
    requestAnimationFrame(function paso(t) {
      marcas.push(t);
      marcas.length < muestras ? requestAnimationFrame(paso) : resolver();
    });
  });
  const deltas = marcas.slice(1).map((t, i) => t - marcas[i]).sort((a, b) => a - b);
  const mediana = deltas[Math.floor(deltas.length / 2)];
  return { hz: Math.round(1000 / mediana), intervaloMs: +mediana.toFixed(2) };
}

console.log(await frecuenciaDePanel());

La tasa de fotogramas perdidos durante una interacción, que es la métrica que de verdad describe la experiencia:

function medirFluidez(duracionMs = 3000) {
  return new Promise((resolver) => {
    const intervalos = [];
    let previo = performance.now();
    const fin = previo + duracionMs;
    requestAnimationFrame(function paso(t) {
      intervalos.push(t - previo);
      previo = t;
      if (t < fin) requestAnimationFrame(paso);
      else {
        const objetivo = intervalos.slice().sort((a, b) => a - b)[Math.floor(intervalos.length / 2)];
        const perdidos = intervalos.filter((d) => d > objetivo * 1.5).length;
        resolver({
          fotogramas: intervalos.length,
          perdidos,
          porcentajePerdido: +((perdidos / intervalos.length) * 100).toFixed(1),
          peorIntervalo: +Math.max(...intervalos).toFixed(1),
        });
      }
    });
  });
}

Ejecuta esa función mientras haces la interacción que te preocupa. El campo porcentajePerdido es la cifra que se puede llevar a una discusión: por debajo del 2% la animación se percibe fluida, por encima del 10% se percibe rota, y en medio depende del tipo de movimiento.

const { porcentajePerdido } = await medirFluidez(1500);
if (porcentajePerdido > 15) {
  document.documentElement.dataset.animacion = 'reducida';
}

/* La version completa */
.tarjeta { transition: transform 300ms cubic-bezier(.2,.8,.2,1), box-shadow 300ms; }

/* La version que el dispositivo sostiene */
[data-animacion='reducida'] .tarjeta { transition: transform 150ms linear; box-shadow: none; }

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}