Huella de tasa de cuadros: frecuencia de pantalla y vídeo

Esta guía trata de la frecuencia de actualización que revela requestAnimationFrame y de la cadencia de los elementos de vídeo. BotBrowser ajusta el ritmo de pantalla con --bot-fps y la cadencia de vídeo con --bot-video-fps; no puede dar a hardware distinto un rendimiento idéntico ni cambiar cómo un sitio interpreta esos intervalos.

Resumen rápido

--bot-fps fija el ritmo de pantalla en modo de perfil, fijo o real, y --bot-video-fps reduce la cadencia visual del vídeo sin tocar ese ritmo. Registra por separado el intervalo de requestAnimationFrame y la cadencia del vídeo en cada modo.

Contenido de esta guía

• Cómo requestAnimationFrame revela la frecuencia de actualización
• Por qué la frecuencia de actualización es una señal de hardware
• Por qué los envoltorios y las extensiones dejan huecos
• Configurar el ritmo de cuadros de pantalla
• Ritmo de reproducción de vídeo y CPU
• Elegir valores y comprobar el resultado

Cómo requestAnimationFrame revela la frecuencia de actualización

Cuando una página llama a requestAnimationFrame(callback), el navegador ejecuta el callback antes del siguiente repintado y le pasa un DOMHighResTimeStamp que marca el inicio del cuadro. La referencia de MDN describe este contrato y señala que los callbacks normalmente coinciden con la frecuencia de actualización de la pantalla. Restar marcas de tiempo consecutivas da el intervalo entre cuadros, y dividir un segundo entre ese intervalo da la frecuencia.

Una estimación fiable solo necesita una muestra corta. Reunir unas decenas de marcas de tiempo consecutivas y promediar los intervalos suaviza los cuadros lentos aislados, y toda la medición termina en una fracción de segundo sin que el visitante note nada. Debe ejecutarse en una pestaña visible, porque los navegadores suelen pausar o ralentizar requestAnimationFrame en las páginas en segundo plano.

Las mediciones reales tienen ruido. Una página ocupada pierde de vez en cuando un cuadro, lo que aparece como un intervalo largo entre muchos regulares, y una sola muestra puede coincidir con ese valor atípico. Tomar la mediana o el promedio de una ejecución más larga da una cifra estable, y esa cifra suele quedar cerca de un valor conocido como 60, 90, 120 o 144 Hz. Esa estabilidad es lo que hace útil el número para un sitio que quiere reconocer un dispositivo que vuelve.

Las animaciones y transiciones CSS avanzan sobre el mismo ciclo de pantalla. Una animación @keyframes de un segundo produce aproximadamente un cuadro por actualización, así que se mueve en pasos más finos en una pantalla de 144 Hz que en una de 60 Hz. La especificación CSS no promete exactitud cuadro a cuadro, pero el ritmo al que progresa una animación sigue siendo el de la pantalla. Esto importa más adelante, porque una página puede leer la frecuencia desde requestAnimationFrame y desde una animación y esperar que ambas lecturas coincidan.

La frecuencia de actualización variable añade otra dimensión. Las pantallas con G-Sync, FreeSync o ProMotion pueden cambiar su frecuencia según el contenido, por ejemplo bajando hacia una frecuencia menor cuando casi nada se mueve. Una página que observa el tiempo suficiente ve no solo una frecuencia base, sino también la manera en que cambia, y ese patrón difiere del ritmo constante de un panel de frecuencia fija.

Los equipos con varios monitores añaden un último matiz. Cuando una ventana pasa de un monitor de 60 Hz a uno de 144 Hz, los intervalos de callback cambian en ese momento. Una página que sigue los intervalos durante una sesión puede notar el cambio, lo que dice algo sobre la disposición del hardware detrás de la ventana del navegador.

Por qué la frecuencia de actualización es una señal de hardware

La frecuencia de actualización pertenece a la pantalla física y al compositor que la maneja. No cambia cuando borras las cookies, abres una ventana privada o cambias de red. Un visitante en la misma máquina puede informar de un ritmo parecido, pero la carga, la frecuencia variable y los cambios de pantalla pueden mover los intervalos observados entre sesiones.

La señal también aporta más información que antes. Hace no mucho casi todos los monitores de consumo funcionaban a 60 Hz, así que el número decía muy poco a un sitio. Hoy hay paneles de 60, 75, 90, 120, 144, 165, 240 y 360 Hz, y los móviles y portátiles con frecuencias adaptativas como ProMotion añaden más variación. Un visitante con un monitor de 165 Hz pertenece a un grupo mucho más pequeño que uno con 60 Hz, de modo que el valor ayuda a acotar de qué dispositivos podría venir una visita. Los navegadores móviles se comportan igual: existen pantallas de 60, 90 y 120 Hz, y muchos móviles modernos cambian de frecuencia mientras funcionan.

La frecuencia de actualización es una señal ligada al hardware entre varias señales de pantalla, y por sí sola no prueba la identidad. Su peso viene de la combinación. Junto con el tamaño de pantalla, la profundidad de color, la relación de píxeles del dispositivo y la salida de la GPU, contribuye a una descripción de hardware mucho más específica que cualquier valor aislado. La guía de huella de pantalla y ventana cubre las señales de pantalla vecinas.

Varias funciones del navegador exponen señales de pantalla relacionadas. Los intervalos de requestAnimationFrame y el progreso de las animaciones CSS siguen el camino de tiempo de la pantalla, mientras que las propiedades de pantalla informadas describen el estado de la ventana y del monitor. Una medida de privacidad que cambie solo una puede dejar que las demás apunten a otro contexto de hardware.

El mismo principio importa a los equipos que ejecutan navegadores en hardware mixto. Los equipos sin interfaz no tienen pantalla física, y las máquinas virtuales y los contenedores suelen informar de tiempos marcados por la carga del anfitrión y no por un monitor real. Un perfil describe un dispositivo con una frecuencia de actualización concreta, y un tiempo visible para la página que no coincide con el perfil es una discrepancia entre el dispositivo declarado y su comportamiento observado. Un perfil de móvil de 120 Hz cuyos callbacks llegan a un ritmo de 60 Hz es un ejemplo.

Por qué los envoltorios y las extensiones dejan huecos

La tasa de cuadros es una propiedad local del hardware que el navegador mide dentro de su propio ciclo de pantalla, así que las herramientas que actúan en otro lugar no la alcanzan. Una VPN o cualquier otra herramienta de red cambia la ruta de las solicitudes y no afecta a los intervalos de los callbacks. La navegación privada cambia dónde se guardan los datos y no cómo se actualiza la pantalla, de modo que una medición en una ventana privada coincide con la de una ventana normal.

Las extensiones y los scripts de página que modifican requestAnimationFrame tienen más margen, pero chocan con límites. Hay tres patrones habituales y cada uno deja un hueco visible.

• Limitar el callback. Un script puede envolver la API y llamar al callback original a una frecuencia objetivo menor. Las animaciones legítimas se entrecortan, y las animaciones CSS siguen funcionando a la frecuencia real de la pantalla, por lo que las dos fuentes de tiempo se contradicen.
• Reescribir las marcas de tiempo. Cambiar el DOMHighResTimeStamp que reciben los callbacks puede imitar otra frecuencia, pero performance.now(), Date.now() y el tiempo de las transiciones CSS siguen informando del ritmo original.
• Bloquear la API. Desactivar requestAnimationFrame rompe las muchas aplicaciones web que la usan para dibujar.

El hilo común es que estas herramientas se sitúan en la capa de JavaScript mientras la frecuencia de pantalla aparece en varios lugares. Cambiar un lugar sin los demás produce una incoherencia, y una incoherencia contradice el dispositivo que describe el perfil.

Los ajustes de desarrollador de algunos navegadores pueden limitar la tasa de cuadros. Un límite restringe la velocidad de renderizado, pero es un techo y no un objetivo elegido. No puedes pedir una frecuencia concreta por sesión, un límite no puede subir la frecuencia por encima de lo que ofrece la pantalla del anfitrión, y la limitación puede mostrarse como artefactos visibles. Un perfil que declara 120 Hz no se puede igualar así desde un anfitrión de 60 Hz.

Configurar el ritmo de cuadros de pantalla

BotBrowser soporta el ritmo de cuadros de pantalla mediante --bot-fps, que acepta profile, real o un número. La opción es un control ENT Tier2, por lo que necesita un perfil con la habilitación ENT Tier2. Con ella activa, el tiempo de requestAnimationFrame sigue la frecuencia elegida en lugar de la que tenga por casualidad la pantalla del anfitrión.

Modo de perfil

En el modo profile, que es el predeterminado, BotBrowser lee la frecuencia de actualización guardada en el perfil cargado y hace que el tiempo de requestAnimationFrame coincida con ella.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=profile

Un perfil describe un dispositivo objetivo. Uno capturado en hardware de 60 Hz informa de un ritmo de 60 Hz, y uno capturado en un dispositivo de 120 Hz o 144 Hz informa del ritmo más rápido, sea cual sea la frecuencia de la pantalla del anfitrión. Para la mayoría de los casos es la elección correcta, porque la frecuencia de actualización sigue unida al resto de la descripción del dispositivo y no exige decidir en cada ejecución.

Valor fijo

Un número fija una frecuencia exacta, y el tiempo de cuadros y los intervalos de renderizado la siguen en cualquier hardware anfitrión.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60

Úsalo cuando una flota mezcla monitores de alta frecuencia con anfitriones sin interfaz cuyo tiempo nativo es irregular, y quieres un mismo ritmo en todas partes. Elige valores que existan en pantallas reales, como 60, 75, 90, 120, 144, 165 o 240. Un valor como 73 o 137 no corresponde a ningún monitor que un visitante probablemente tenga, así que contradiría la pantalla que describe el perfil.

Modo real

El valor real usa la frecuencia nativa de la pantalla del anfitrión.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=real

Sirve cuando el hardware del anfitrión ya coincide con el objetivo del perfil. También es un diagnóstico práctico. Ejecutar la misma página con real y con profile muestra si la inestabilidad viene de la carga de renderizado del anfitrión o de los ajustes del perfil.

La opción --bot-fps gobierna solo el tiempo de pantalla y de ejecución. La reproducción de vídeo tiene su propio control, que se describe a continuación, de modo que una página puede mantener un ritmo de pantalla de 60 Hz mientras sus elementos de vídeo se actualizan menos.

Ritmo de reproducción de vídeo y CPU

Los elementos de vídeo siguen decodificando y pintando cuadros incluso cuando el flujo de trabajo solo lee texto, respuestas de red, el estado del DOM o alguna captura ocasional. En una página de monitorización, un panel de colas o un catálogo con mucho contenido multimedia, esa decodificación puede ser el mayor coste individual por pestaña, y crece con el número de pestañas.

BotBrowser soporta --bot-video-fps=<actual>[:<reported>] para este caso. Es un control ENT Tier2 y funciona en perfiles con Video FPS Control habilitado. Los perfiles que no lo tienen ignoran la opción.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-video-fps=1:30

La opción admite tres formas.

• --bot-video-fps=1 decodifica y renderiza el vídeo cerca de 1 FPS e informa de 1 FPS.
• --bot-video-fps=1:30 renderiza el vídeo cerca de 1 FPS mientras la información multimedia usa 30 FPS.
• --bot-video-fps=1:real renderiza el vídeo cerca de 1 FPS e informa de la cadencia que declara el propio contenido multimedia cuando está disponible.

El primer valor es la cadencia visual real, que controla con qué frecuencia se actualizan los cuadros de vídeo. El segundo valor es la política de información multimedia, y si se omite se informa del valor real. El ajuste real mantiene los valores informados alineados con la cadencia que declara el contenido, no con la cadencia real reducida.

La salida de píxeles sigue la cadencia real, y ese es el único límite que hay que planificar. Un flujo de trabajo que muestrea píxeles de vídeo cuadro a cuadro, o que toma capturas que deben mostrar contenido de vídeo reciente, verá la cadencia reducida. Para esos flujos elige un valor real más alto, como 5:30 o 10:30, o deja la opción sin usar. Una captura que muestra el vídeo a la cadencia menor es el comportamiento configurado, no un fallo.

El mismo razonamiento vale para cualquier comprobación que juzgue la calidad de la reproducción. Una prueba que cuenta cuadros perdidos, verifica que la reproducción sea fluida o compara cuadros de vídeo consecutivos mide la cadencia real, así que necesita la frecuencia completa y debe ejecutarse sin --bot-video-fps. La opción encaja en el caso contrario, cuando el vídeo es material de fondo y el trabajo ocurre en el DOM, en la red o en el texto de la página.

La prueba comparativa pública de BotBrowser mide el efecto en una carga de trabajo con mucho vídeo. La prueba usó una compilación oficial de Linux x64 en modo sin interfaz, con vídeo AVC local de 640 por 360 píxeles y 30 FPS en cada elemento, 10 segundos de calentamiento, una ventana de muestreo de 30 segundos y 3 repeticiones por ajuste. Se comparó la política base 30:30 con 1:30.

Vídeos simultáneos	CPU media base	CPU media con 1:30	Reducción
8	33,96 %	9,70 %	71,43 %
16	61,20 %	12,10 %	80,24 %
24	76,49 %	13,81 %	81,95 %

Estas cifras describen una carga de trabajo en una plataforma. El uso de CPU varía con el anfitrión, el controlador, el códec y el contenido de la página, así que lee el rango de 71 a 82 % como una referencia de una prueba con mucho vídeo en la que una cadencia visual menor era aceptable, no como un ahorro que esperar en todas partes. La prueba comparativa de Video FPS Control detalla la configuración completa.

Cuando se usan ambos controles a la vez, el tiempo de pantalla mantiene su ritmo de 60 Hz mientras los elementos de vídeo se actualizan menos.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60 \
  --bot-video-fps=1:30

Elegir valores y comprobar el resultado

Trata los FPS de pantalla y los FPS de vídeo como dos decisiones con responsables distintos. Los FPS de pantalla forman parte de la descripción del dispositivo, así que deben coincidir con el perfil cargado, salvo que pruebes a propósito otra clase de pantalla. Un perfil de portátil de oficina de 60 Hz, un perfil móvil de 120 Hz y un perfil de escritorio de alta frecuencia no deben mezclarse a la ligera, porque el tiempo de cuadros está junto al tamaño de pantalla, la relación de píxeles del dispositivo, la salida de la GPU y el tiempo de las animaciones. La guía de gestión de perfiles cubre cómo se guardan y se rotan los perfiles.

Los FPS de vídeo son una decisión operativa. Empieza con un valor conservador: 1:30 cuando bastan actualizaciones visuales ocasionales, y una cadencia real más alta cuando las capturas necesitan cuadros más recientes. La comparación de píxeles de vídeo cuadro a cuadro es el caso que descarta los valores muy bajos.

Para las flotas, deja escrita la política por carga de trabajo. Mantén una política para las páginas que necesitan reproducción visual completa, otra para las páginas de fondo que llevan contenido multimedia y otra para los flujos de capturas. Una política escrita facilita revisar más adelante los cambios de rendimiento y separa el ajuste de la carga de trabajo de las decisiones de coherencia del perfil.

Para comprobar el resultado, mide dentro de una pestaña visible. Reúne las marcas de tiempo de unos sesenta callbacks consecutivos de requestAnimationFrame, promedia los intervalos y compara la frecuencia resultante con la configurada. Después compárala con una lectura tomada de una animación CSS. Para el vídeo, compara el uso de CPU y la cadencia visible con y sin --bot-video-fps. Las ejecuciones sin interfaz y con interfaz pueden diferir bajo carga, así que valida ambas con el mismo perfil y las mismas opciones. La guía de coherencia entre modo sin interfaz y con interfaz cubre esas diferencias.

Convertir muestras de tiempo en una comprobación de fallos

Este muestreador registra 120 intervalos de callbacks de animación consecutivos. Ejecútalo en la consola DevTools de la página mientras la pestaña siga visible; la mediana estima la cadencia habitual y el percentil 95 muestra una cola de cuadros retrasados que un promedio puede ocultar.

const intervals = [];
let previous;
let valid = document.visibilityState === 'visible';
if (!valid) console.log('sample invalid: open the page in a visible tab');
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'visible') {
    valid = false;
    console.log('sample invalid: tab became hidden');
  }
});
function sample(timestamp) {
  if (!valid) return;
  if (previous !== undefined) intervals.push(timestamp - previous);
  previous = timestamp;
  if (intervals.length < 120) {
    requestAnimationFrame(sample);
    return;
  }
  const sorted = [...intervals].sort((a, b) => a - b);
  const middle = sorted.length / 2;
  const medianIntervalMs = (sorted[middle - 1] + sorted[middle]) / 2;
  const p95IntervalMs = sorted[Math.ceil(sorted.length * 0.95) - 1];
  console.log(
    JSON.stringify({
      visible: valid && document.visibilityState === 'visible',
      intervalCount: intervals.length,
      medianIntervalMs: Number(medianIntervalMs.toFixed(2)),
      p95IntervalMs: Number(p95IntervalMs.toFixed(2)),
      estimatedHz: Number((1000 / medianIntervalMs).toFixed(1)),
    })
  );
}
if (valid) requestAnimationFrame(sample);

Lee la muestra como una comprobación de ramas, no como un veredicto del dispositivo:

Observación	Qué establece	Siguiente comprobación
La pestaña se oculta antes de terminar 120 intervalos	La limitación en segundo plano invalidó la muestra	Mantén la pestaña visible y repite la misma captura
La mediana se acerca a la frecuencia elegida, pero p95 es mucho mayor	Existe la cadencia regular, con cuadros retrasados en la cola	Repite en un anfitrión inactivo e inspecciona CPU/GPU antes de cambiar el perfil
La mediana sigue real, pero no la frecuencia declarada por el perfil	El tiempo del anfitrión y el del perfil no coinciden	Confirma el argumento --bot-fps activo y la frecuencia de pantalla del perfil
requestAnimationFrame coincide mientras el vídeo avanza despacio con 1:30	La cadencia de pantalla y la de vídeo están separadas como se configuró	Quita el límite de vídeo para píxeles cuadro a cuadro o comprobaciones de reproducción

La lista de problemas existente cubre la deriva y el vídeo lento. Estas filas añaden una forma reproducible de distinguir una muestra de fondo inválida, una cola de jitter, una diferencia entre anfitrión y perfil y un límite de vídeo intencionado antes de cambiar cualquiera de los controles.

La mayoría de los problemas encajan en unos pocos patrones.

• La frecuencia medida se desvía del valor configurado: revisa si la CPU y la GPU del anfitrión están saturadas, porque una carga de renderizado alta puede añadir inestabilidad alrededor de la frecuencia objetivo.
• El perfil dice 120 Hz pero la medición se acerca a 60: confirma que --bot-fps no esté fijado a 60 y revisa los argumentos de arranque del proceso en ejecución.
• El vídeo informa de 30 FPS pero parece lento: es lo esperado con --bot-video-fps=1:30, porque los FPS informados y la cadencia visual están separados por diseño.
• La opción de vídeo sigue inactiva si el perfil no ofrece Video FPS Control; comprueba esa capacidad antes de cambiar --bot-video-fps.

El ritmo de cuadros es solo una parte del tiempo de ejecución que una página puede observar. La guía de tiempos de rendimiento cubre las señales de tiempo que lo acompañan.

BotBrowser soporta ajustar el ritmo de cuadros de pantalla con --bot-fps (profile, real o un valor fijo) y la cadencia de reproducción de vídeo con --bot-video-fps en perfiles con Video FPS Control habilitado, de modo que el tiempo de requestAnimationFrame sigue el perfil elegido y las páginas con mucho vídeo pueden usar menos CPU. Para ti, eso significa una frecuencia de actualización acorde con el dispositivo que elegiste y un gasto de CPU menor en páginas llenas de vídeo, con los FPS de pantalla y de vídeo decididos por separado. BotBrowser no activa estos controles sin la habilitación ENT Tier2 del perfil, no aplica --bot-video-fps en perfiles sin Video FPS Control, no puede garantizar el mismo ahorro de CPU fuera de la carga probada y no sustituye la elección de un perfil cuyas señales de pantalla, GPU y tiempo sean coherentes.

Qué añade frente a la página de referencia

La página de referencia describe los controles de pantalla. La comparación añadida registra por separado los intervalos de requestAnimationFrame y la cadencia de vídeo en modo de perfil, fijo y real. Si la animación es estable pero el vídeo no, revisa el flujo multimedia y la carga del host.

Fuentes públicas

• MDN: Window.requestAnimationFrame(): tiempo de los callbacks y el argumento DOMHighResTimeStamp.
• MDN: Using CSS animations: cómo progresan las animaciones CSS.
• BotBrowser FPS Control: modos de --bot-fps y comportamiento de --bot-video-fps.
• Prueba comparativa de BotBrowser: mediciones de CPU de Video FPS Control.

Conclusión práctica

Empieza con un valor conservador, como 1:30 cuando bastan actualizaciones visuales ocasionales, y sube la cadencia real si las capturas necesitan cuadros recientes.