Se necesitan comentarios de desarrolladores: API de Frame Timing

En los últimos años, los navegadores han dado grandes pasos en términos de rendimiento de renderización, en especial en dispositivos móviles. Si antes no tenías esperanzas de alcanzar una velocidad de fotogramas fluida para cualquier contenido remotamente complejo, hoy en día, al menos, es posible lograrlo si tienes cuidado.

Sin embargo, para la mayoría de nosotros, existe una desconexión entre lo que podemos probar de manera razonable en nuestros propios dispositivos y lo que experimentan nuestros usuarios. Si no obtienen una experiencia fluida a 60 fps, su experiencia se verá afectada y, en última instancia, se irán a otro lugar, lo que nos perjudicará. Por lo tanto, es bueno que el W3C esté analizando una nueva API que podría ayudarnos a ver lo que ven nuestros usuarios: la API de Frame Timing.

Recientemente, Jake Archibald y yo grabamos una descripción general en video de la API, así que, si prefieres mirar en lugar de leer, mira este video:

Usos de la API de Frame Timing

Sin duda, hay muchas cosas que puedes hacer con la API de Frame Timing y, lo que es más importante, puedes medir lo que es importante para ti y para tu proyecto. Aun así, aquí tienes algunas ideas:

  • Hacer un seguimiento de los fps de tus animaciones de JavaScript y CSS
  • Hacer un seguimiento de la fluidez del desplazamiento de la página (o tal vez de esa lista de desplazamiento infinito que tienes)
  • Reducir automáticamente los efectos de Showbiz según la carga actual del dispositivo
  • Pruebas de regresión en las métricas de rendimiento del entorno de ejecución

La presentación breve

A continuación, se muestra cómo se ve actualmente la API en la especificación: con ella, puedes extraer datos sobre el tiempo de la subproceso del renderizador, donde se ejecutan JavaScript, los diseños y los estilos. (Es posible que hayas escuchado que el subproceso del renderizador se llama subproceso principal; es lo mismo con otro nombre).

var rendererEvents = window.performance.getEntriesByType("renderer");

Cada uno de los registros del subproceso del renderizador que obtienes se ve de la siguiente manera:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

Cada registro es, en esencia, un objeto que contiene un número de fotograma único, una marca de tiempo de alta resolución para el momento en que se inició el fotograma y otra para la cantidad de tiempo de CPU que usó. Con un array de estos, puedes observar cada uno de los valores de startTime y descubrir si el subproceso principal funciona a 60 fps; en esencia, "¿el startTime de cada fotograma aumenta en fragmentos de aproximadamente 16 ms?".

Pero, además de eso, también obtienes el cpuTime, por lo que sabrás si estás dentro del límite de 16 ms o si te quedaste al límite. Si el cpuTime está cerca del límite de 16 ms, no hay mucho espacio para que se activen elementos como la recolección de basura y, con un uso alto de la CPU, el consumo de batería también será mayor.

Además del subproceso del renderizador, también puedes extraer datos sobre el tiempo del subproceso del compositor, donde se producen la pintura y la composición:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

Cada uno de ellos también muestra un número de fotograma de origen, que puedes usar para vincularlo a los eventos del subproceso principal:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Debido a la forma en que suele funcionar la composición en los navegadores, puede haber varios de estos registros por registro de subproceso del renderizador, por lo que puedes usar sourceFrameNumber para volver a unirlos. También hay algunas discusiones sobre si también debería haber tiempo de CPU en estos registros, así que, si tienes una opinión firme, comunícate con los problemas de GitHub.

Más información

Esta API aún no se envía, pero esperamos que lo haga pronto. Mientras tanto, puedes leer y hacer lo siguiente: