Hacia una métrica de fluidez de animación

Obtén información sobre cómo medir animaciones, analizar los fotogramas de animación y la fluidez general de la página.

Behdad Bakhshinategh

Jonathan Ross

Michal Mocny

Probablemente hayas visto páginas que se "interrumpen" o "inmovilizar" mientras te desplazas o animaciones. Nos gusta decir que estas experiencias no son suaves. Dirección de destino estos tipos de problemas, el equipo de Chrome ha estado trabajando para agregar más asistencia a nuestras herramientas de laboratorio para detectar animaciones y realizar mejoras constantes en el diagnóstico de la canalización de renderización en Chromium.

Nos gustaría compartir algunos avances recientes, ofrecer orientación concreta sobre herramientas y analizar ideas para métricas futuras de fluidez de animación. Como siempre, nos encantaría para escuchar tus comentarios.

En esta publicación, se abordarán tres temas principales:

• Un vistazo rápido a las animaciones y los marcos de animación.
• Nuestras ideas actuales sobre cómo medir la fluidez general de las animaciones.
• Algunas sugerencias prácticas que puedes aprovechar hoy mismo en las herramientas del lab.

¿Qué son las animaciones?

Las animaciones le dan vida al contenido. Si logras que el contenido se mueva, especialmente en respuesta a las interacciones de los usuarios, las animaciones pueden hacer que una experiencia se sienta más natural, comprensible y divertida.

Pero las animaciones mal implementadas o simplemente agregar demasiadas animaciones, pueden degradar la experiencia y hacer que definitivamente no sea divertida. Probablemente todos interactuamos con una interfaz que acaba de agregar demasiados recursos "útiles" transición que, de hecho, se vuelven hostiles de experimentar cuando tienen un rendimiento deficiente. Por lo tanto, algunos usuarios podrían preferir el movimiento reducido, una preferencia del usuario que debes honrar.

¿Cómo funcionan las animaciones?

A modo de resumen, la canalización de renderización consta de algunas etapas secuenciales:

1. Estilo: calcula el los estilos que se aplican a los elementos.
2. Diseño: Genera el la geometría y la posición de cada elemento.
3. Pintura: Completa la píxeles de cada elemento en capas.
4. Compuesto: Dibuja el capas a la pantalla.

Si bien existen muchas formas de definir animaciones, todas funcionan fundamentalmente a través de una de las siguientes opciones:

• Ajustar el diseño propiedades.
• Ajustando la pintura propiedades.
• Ajustar compuesto propiedades.

Debido a que estas etapas son secuenciales, es importante definir animaciones en y términos de las propiedades que se encuentran más adelante en la canalización. Cuanto antes sea la actualización cuanto más grandes sean los costos y es menos probable que sin problemas. (Consulta Renderización rendimiento para obtener más información).

Si bien puede ser conveniente animar propiedades de diseño, existen costos hacerlo, incluso si esos costos no son evidentes de inmediato. Las animaciones deben ser definidos en términos de propiedades compuestas cambia siempre que sea posible.

Definir animaciones de CSS declarativas o usar Web Animaciones, y asegurarse de animar las imágenes propiedades, es un excelente primer paso para garantizar animaciones fluidas y eficaces. Pero aun así, esto por sí solo no garantiza la fluidez porque incluso las animaciones web eficientes tener límites de rendimiento. Por eso, siempre es importante realizar mediciones.

¿Qué son los fotogramas de animación?

Las actualizaciones en la representación visual de una página tardan en aparecer. Un elemento visual nuevo generará un nuevo fotograma de animación, que finalmente se renderiza en el la pantalla del usuario.

Las pantallas se actualizan en algún intervalo, por lo que las actualizaciones visuales se agrupan en lotes. Muchas pantallas actualizar en un intervalo de tiempo fijo, como 60 veces por segundo (es decir, 60 Hz). Algunas pantallas más modernas pueden ofrecer frecuencias de actualización más altas (Cada vez son más comunes los de 90 a 120 Hz). A menudo, estas pantallas pueden adaptarse de manera activa entre las frecuencias de actualización según sea necesario o incluso ofrecer velocidades de fotogramas totalmente variables.

El objetivo de cualquier aplicación, como un juego o un navegador, es procesar todas estas actualizaciones visuales por lotes y producir un marco de animación visualmente completo en la fecha límite, siempre. Ten en cuenta que este objetivo es completamente distinto de otros tareas importantes del navegador, como cargar contenido desde la red rápidamente o ejecutar tareas de JavaScript de forma eficiente.

En algún momento, puede ser demasiado difícil completar todas las actualizaciones visuales la fecha límite asignada que se asignó a la pantalla. Cuando esto sucede, el navegador cae un fotograma. La pantalla no se pone negra, solo se repite. Verás la misma actualización visual por un poco más de tiempo, con el mismo marco de animación que que se presentó en la oportunidad de fotograma anterior.

Esto sucede a menudo. No necesariamente es perceptible, especialmente para contenido estático o similar a un documento, que es común en la plataforma web en en particular. Los fotogramas descartados solo se hacen evidentes cuando hay elementos visuales importantes como las animaciones, para las cuales necesitamos un flujo constante de animaciones actualizaciones para mostrar un movimiento suave.

¿Qué factores influyen en los fotogramas de animación?

Los desarrolladores web pueden influir en gran medida en la capacidad de un navegador para realizar para renderizar y presentar actualizaciones visuales de forma eficiente.

Estos son algunos ejemplos:

• Usar contenido que es demasiado grande o que usa muchos recursos para decodificarse rápidamente en el dispositivo de destino.
• Se están usando demasiados capas sin requerir demasiada memoria de GPU.
• Definir estilos de CSS o animaciones web demasiado complejos
• Usar antipatrones de diseño que inhabilitan las optimizaciones de renderización rápida.
• Demasiado trabajo de JS en el subproceso principal, lo que lleva a tareas largas que bloquean la visualización actualizaciones.

Pero ¿cómo es posible saber cuándo un fotograma de animación no cumplió con su plazo y causó un fotograma descartado?

Un método posible es usar requestAnimationFrame() y encuestas, pero tiene varias desventajas. requestAnimationFrame() o "rAF", le indica al navegador que deseas realizar una animación y solicita una para hacerlo antes de la siguiente etapa de pintura de la canalización. Si no se llama a la función de devolución de llamada en el momento esperado, lo que significa que no se ejecutó la pintura y se omitieron uno o más fotogramas. A través de sondeos y con la frecuencia con la que se llama a rAF, se puede calcular una especie de "fotogramas por segundo" (FPS).

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

Usar el sondeo de requestAnimationFrame() no es una buena idea por varios motivos:

• Cada secuencia de comandos debe configurar su propio bucle de sondeo.
• Puede bloquear la ruta crítica.
• Incluso si el sondeo de rAF es rápido, puede evitar requestIdleCallback() de programar bloques de inactividad largos cuando se usan continuamente (bloques que superen un solo fotograma).
• Del mismo modo, la falta de bloques de inactividad prolongados evita que el navegador programe otras tareas de larga duración (como una recolección de elementos no utilizados más extensa y otras tareas el trabajo especulativo).
• Si el sondeo está activado o desactivado, omitirás los casos en los que el presupuesto de fotogramas se superó.
• Las encuestas informarán falsos positivos en los casos en que el navegador esté utilizando frecuencia de actualización variable (por ejemplo, debido al estado de energía o visibilidad)
• Y lo más importante es que no captura todos los tipos de animaciones actualizaciones

Demasiado trabajo en el subproceso principal puede afectar la capacidad de ver los fotogramas de animación. Echa un vistazo al bloqueo de muestra para ver cómo se Animación basada en rAF, cuando hay demasiado trabajo en el subproceso principal (como ), disminuirá los fotogramas y disminuirá las devoluciones de llamada de rAF y disminuirá los FPS.

Cuando el subproceso principal se enreda, las actualizaciones visuales comienzan a interrumpirse. ¡Qué bloqueo!

Muchas herramientas de medición se han centrado principalmente en la capacidad de los principales para que el subproceso se realice de manera oportuna y para que los fotogramas de animación se ejecuten sin problemas. ¡Pero esta no es toda la historia! Consulta el siguiente ejemplo:

En el video anterior, se muestra una página que inserta tareas largas en la página principal conversación. Estas tareas largas arruinan por completo la capacidad de la página de proporcionar ciertos tipos de actualizaciones visuales. En la esquina superior izquierda, caída correspondiente de los FPS informados de requestAnimationFrame() a 0.

Sin embargo, a pesar de estas tareas largas, la página continúa desplazándose con fluidez. Esta es que, en los navegadores modernos, el desplazamiento suele ser subprocesos, completamente impulsada por el compositor.

Este es un ejemplo que contiene simultáneamente muchos fotogramas descartados en la parte pero aún tiene muchos fotogramas de desplazamiento entregados con éxito en la subproceso del compositor. Una vez que se complete la tarea larga, se actualizará la pintura del subproceso principal. no ofrece ningún cambio visual. El sondeo de rAF sugirió una caída de fotogramas a 0, pero visualmente, un usuario no podría notar una diferencia.

Para los marcos de animación, la historia no es tan simple.

Marcos de animación: Actualizaciones importantes

El ejemplo anterior demuestra que la historia no solo es requestAnimationFrame()

Entonces, ¿cuándo son importantes las actualizaciones y los marcos de animación? Estas son algunos criterios en los que estamos pensando y nos encantaría recibir sus comentarios:

• Actualizaciones del subproceso principal y del compositor
• Faltan actualizaciones de pintura
• Cómo detectar animaciones
• Calidad frente a cantidad

Actualizaciones del subproceso principal y del compositor

Las actualizaciones de marcos de animación no son booleanas. No se trata de que los fotogramas solo se descarten o se presenten por completo. Hay muchas razones por las que una animación El marco se puede presentar parcialmente. En otras palabras, puede tener simultáneamente contenido obsoleto y, al mismo tiempo, algunas actualizaciones visuales nuevas presentada.

El ejemplo más común es cuando el navegador no puede producir una nueva actualización del subproceso principal dentro del plazo del marco, pero tiene un subproceso compositor nuevo (como el ejemplo de desplazamiento en subprocesos anterior).

Una razón importante por la que usar animaciones declarativas para animar la composición se recomienda que, al hacerlo, se pueda generar una animación completamente por el subproceso compositor, incluso cuando el subproceso principal está ocupado. Estos tipos de animaciones pueden seguir produciendo actualizaciones visuales de forma eficiente y en paralelo.

Por otro lado, puede haber casos en los que una actualización del subproceso principal finalmente se convierte en disponible para la presentación, pero solo después de incumplir varios plazos de marcos. Aquí El navegador tendrá una actualización nueva, pero es posible que no sea la más reciente.

En términos generales, consideramos los marcos que contienen algunas actualizaciones visuales nuevas, sin todas las actualizaciones visuales nuevas, como un marco parcial. Los fotogramas parciales son bastante comunes. Idealmente, las actualizaciones parciales incluyen al menos actualizaciones visuales, como animaciones, pero eso solo puede ocurrir si las animaciones impulsada por el subproceso compositor.

Faltan actualizaciones de pintura

Otro tipo de actualización parcial es cuando el contenido multimedia, como las imágenes, no ha terminado. decodificando y rasterizando a tiempo para la presentación del marco.

O incluso si una página es totalmente estática, es posible que los navegadores aún tengan problemas para renderizarse actualizaciones visuales durante un desplazamiento rápido. Eso se debe a que los formatos de píxeles de el contenido más allá del viewport visible podría descartarse para ahorrar memoria de la GPU. Integra tarda en renderizar los píxeles y puede tardar más que un solo fotograma renderizar todo después de un desplazamiento grande, como deslizar el dedo por la pantalla Por lo general, conocido como checkerboarding.

Con cada oportunidad de procesamiento de fotogramas, es posible realizar un seguimiento las últimas actualizaciones visuales realmente llegaron a la pantalla. Medir la capacidad para hacerlo para muchos fotogramas (o tiempo) se conoce ampliamente como capacidad de procesamiento de fotogramas.

Si la GPU está muy enredada, es posible que el navegador (o la plataforma) incluso comience a limitar la velocidad a la que intenta realizar actualizaciones visuales y, por lo tanto, disminuye las velocidades de fotogramas efectivas. Si bien, técnicamente, eso puede reducir la cantidad de caídas actualizaciones de fotogramas, visualmente aparecerá como una capacidad de procesamiento de fotogramas menor.

Sin embargo, no todos los tipos de capacidad de procesamiento de fotogramas baja son malos. Si la página está mayormente inactiva y no hay animaciones activas, una velocidad de fotogramas baja es igual de visualmente tiene una velocidad de fotogramas alta y puede ahorrar batería.

¿Cuándo es importante la capacidad de procesamiento de los fotogramas?

Cómo detectar animaciones

La alta capacidad de procesamiento de fotogramas es importante animaciones. Los diferentes tipos de animación dependerán de las actualizaciones visuales de una subproceso específico (principal, compositor o trabajador), por lo que su actualización visual es dependiendo de si ese subproceso proporciona la actualización dentro del plazo. Decimos que un subproceso determinado afecta la fluidez cuando hay una animación activa que depende de la actualización del subproceso.

Algunos tipos de animaciones son más fáciles de definir y detectar que otros. Las animaciones declarativas, o las animaciones controladas por el usuario, son más claras de definir que las animaciones basadas en JavaScript implementadas como actualizaciones periódicas propiedades de diseño.

Incluso con requestAnimationFrame() tú no siempre puede suponer que cada llamada de rAF produce necesariamente una una actualización o animación. Por ejemplo, usar sondeo de rAF solo para registrar la velocidad de fotogramas (como se muestra más arriba) no debería afectar por sí misma las mediciones de suavidad, ya que hay sin actualización visual.

Calidad frente a cantidad

Por último, detectar animaciones y actualizaciones de marcos de animación es solo una parte la historia porque solo captura la cantidad de actualizaciones de la animación, no las calidad.

Por ejemplo, podrás ver una velocidad de fotogramas constante de 60 FPS mientras miras una video. Técnicamente, esto es perfectamente fluido, pero el video en sí puede tener un una tasa de bits baja o problemas con el almacenamiento en búfer de la red. Esto no es capturado por las métricas de fluidez de la animación directamente, pero aun así pueden ser molestas para el usuario.

O bien, un juego que aprovecha <canvas> (quizás incluso usando técnicas como fuera de pantalla lienzo en una velocidad de fotogramas constante) puede ser técnicamente fluida en términos de y los fotogramas de animación, pero no pueden cargar elementos de alta calidad o mostrar artefactos de renderización.

Por supuesto, un sitio puede tener animaciones muy malas 🙂

Quiero decir, creo que fueron bastante geniales para su tiempo.

Estados de un solo fotograma de animación

Debido a que los fotogramas se pueden presentar de forma parcial o que la disminución de fotogramas puede ocurrir de maneras que no afectan la suavidad, comenzamos a pensar que cada fotograma tiene puntuación de exhaustividad o fluidez.

Este es el espectro de las maneras en las que interpretamos el estado de una sola fotograma de animación, ordenado del mejor al peor de los casos:

Es posible convertir estos estados en una especie de puntuación. Y quizás una manera para interpretar esta puntuación es considerarla una probabilidad de que sea observable del usuario. Un solo fotograma descartado puede no ser muy observable, pero una secuencia de muchos fotogramas descartados que afectan la suavidad en una fila, ¡seguro!

Revisión general: una métrica de porcentaje de fotogramas descartados

Si bien a veces puede ser necesario profundizar en el estado de cada marco de animación, también es útil asignar una vista rápida puntuación de una experiencia.

Los fotogramas se pueden presentar parcialmente e incluso se pueden omitir por completo. es posible que las actualizaciones de fotogramas no afecten la fluidez, queremos enfocarnos menos en contar fotogramas y más en el extremo en que el navegador no puede Proporcionar actualizaciones visualmente completas cuando sea necesario.

El modelo mental debe avanzar de lo siguiente:

1. Fotogramas por segundo, hasta
2. Detectar actualizaciones de animación faltantes e importantes para
3. Porcentaje descartado durante un período determinado.

Lo que importa es: la proporción de tiempo que esperas actualizaciones. Creemos que esto coincide con la forma natural en que los usuarios experimentan la fluidez del contenido web en la práctica. Hasta ahora, usamos lo siguiente como un conjunto inicial de métricas:

• Porcentaje promedio descartado: para todos los fotogramas de animación no inactivos en la toda la línea de tiempo
• El peor caso de los fotogramas descartados por porcentaje: se mide en un deslizamiento de 1 segundo períodos de tiempo.
• Percentil 95 de fotogramas descartados: según la medición durante 1 segundo períodos variables de tiempo.

Actualmente, puedes encontrar estas puntuaciones en algunas herramientas para desarrolladores de Chrome. Aunque estos se enfocan únicamente en la capacidad de procesamiento general de fotogramas, también evaluamos factores como la latencia de fotogramas.

Pruébalo en herramientas para desarrolladores.

HUD de rendimiento

Chromium tiene un interesante HUD de rendimiento oculto detrás de una marca. (chrome://flags/#show-performance-metrics-hud). En ella, puedes encontrar videos puntuaciones como Métricas web esenciales y algunas definiciones experimentales para la fluidez de la animación según el porcentaje de fotogramas descartados a lo largo del tiempo.

Estadísticas de renderización de fotogramas

Habilitar "Renderización de marcos" Estadísticas" en Herramientas para desarrolladores a través de la configuración de renderización para obtener una visualización en vivo de nuevos fotogramas de animación que están codificados por colores para diferenciar las actualizaciones parciales de los fotogramas completamente descartados actualizaciones. Los FPS informados son solo para fotogramas que se presentan por completo.

Visualizador de fotogramas en las grabaciones del perfil de rendimiento de Herramientas para desarrolladores

La herramienta DevTools Performance panel tiene durante mucho tiempo tenían un Frames o visualizador. Sin embargo, había desordenado un poco la forma en que la canalización de renderización moderna no funciona. Hubo muchas mejoras recientes, incluso en los últimos lanzamientos Chrome Canary, que creemos que facilitará considerablemente los problemas de animación de depuración.

Hoy descubrirás que los cuadros en los fotogramas del usuario se alinean mejor con límites de vsync, y se debe codificar por colores según el estado. Todavía no hay espacio visual de todos los matices descritos anteriormente, pero planeamos agregar más en un futuro cercano.

Registro de Chrome

Por último, con Chrome Tracing, la herramienta elegida para ahondar en los detalles, puedes grabar una instancia de “Renderización de contenido web” realizar un seguimiento con el nuevo Perfetto de usuario (o about:tracing), y analice en detalle las funciones canalización de gráficos. Puede ser una tarea abrumadora, pero hay algunas cosas recientemente agregados a Chromium para que sea más fácil. Puedes obtener una visión general disponible en la página La vida de un Marco .

A través de los eventos de seguimiento, puedes determinar definitivamente lo siguiente:

• Qué animaciones se están ejecutando (con eventos llamados TrackerValidation)
• Obtener la línea de tiempo exacta de los fotogramas de animación (mediante eventos llamados PipelineReporter).
• Para acceder a las actualizaciones de animaciones con bloqueos, averigua exactamente qué está bloqueando que la animación se ejecute más rápido (con los desgloses de eventos en PipelineReporter).
• Para las animaciones basadas en entradas, consulta cuánto tiempo lleva obtener una actualización visual (con eventos llamados EventLatency).

¿Qué sigue?

El objetivo de la iniciativa Métricas web es brindar métricas y orientación creando excelentes experiencias del usuario en la web. Métricas basadas en labs, como Total El tiempo de bloqueo (TBT) es vital para detectar y diagnosticar posibles problemas de interactividad. Tenemos previsto diseñar una métrica similar basada en labs para lograr una animación fluida

Te mantendremos al tanto a medida que continuemos trabajando en las ideas para diseñar una Es una métrica integral basada en datos de fotogramas de animación individuales.

En el futuro, también nos gustaría diseñar APIs que permitan medir la fluidez de la animación de manera eficaz para los usuarios reales field y en el lab. No te pierdas las novedades.

Comentarios

Nos entusiasman todas las mejoras y herramientas para desarrolladores recientes que se envía en Chrome para medir la fluidez de las animaciones. Prueba estas herramientas, comparar tus animaciones y hacernos saber adónde te dirigirán.

Puedes enviar tus comentarios a la web-vitals-feedback Google grupo con “[Métricas de fluidez]” en la línea del asunto. Realmente buscamos ¡con ganas de escuchar lo que piensas!