Se necesitan comentarios de desarrolladores: API de Frame Timing

En los últimos años, los navegadores han avanzado enormemente en términos de rendimiento de representación, especialmente en dispositivos móviles. Antes no tenías la esperanza de alcanzar una velocidad de fotogramas fluida para cualquier cosa remotamente compleja, pero en la actualidad es al menos alcanzable si tienes cuidado.

Sin embargo, para la mayoría de nosotros existe una desconexión entre lo que podemos probar razonablemente en nuestros propios dispositivos y lo que experimentan los usuarios. Si no consiguen 60 fps con una calidad fluida, su experiencia se ve afectada y, finalmente, se irán a otro lado y nosotros sufriremos. De igual manera, el W3C está debatiendo sobre una nueva API que podría ayudarnos a ver lo que ven nuestros usuarios: la API de Frame Timing.

Jake Archibald y yo grabamos hace poco un video con una descripción general de la API, así que si prefieren ver videos en lugar de leer, echen un vistazo:

Usos de la API de Frame Timing

Sin duda, puedes hacer muchas cosas 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í, estas son algunas ideas:

  • Realizar un seguimiento de los FPS de tus animaciones de JavaScript y CSS
  • Hacer un seguimiento de la fluidez de los desplazamientos de tu página (o quizás esa excelente lista de desplazamiento infinito que tengas).
  • Aumenta la escala automáticamente 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 concisa

Así se ve la API actualmente en la especificación: con ella podrás extraer datos sobre la sincronización del subproceso del procesador, donde se ejecutan JavaScript, los estilos y el diseño. (Es posible que hayas escuchado al subproceso del procesador denominado subproceso principal; se trata de lo mismo con otro nombre).

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

Cada uno de los registros de subprocesos del procesador que se obtienen tiene un aspecto similar al siguiente:

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

En esencia, cada registro es 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 otro para el tiempo de CPU que usó. Con un array de estos, puedes observar cada uno de los valores de startTime y averiguar si el subproceso principal avanza a 60 FPS. Básicamente, ¿el startTime de cada fotograma sube en fragmentos de alrededor de 16 ms?

Pero más que eso, también obtienes el cpuTime, por lo que sabrás si estás dentro del límite de 16 ms o si estuviste cómodo. Si cpuTime está cerca del límite de 16 ms, no hay mucho espacio para cosas como la recolección de elementos no utilizados y, con un uso alto de la CPU, el consumo de batería también será mayor.

Además del subproceso del procesador, también puedes extraer datos sobre la sincronización del subproceso del compositor, en los que se llevan a cabo la pintura y la composición:

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

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

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Debido a la forma en que la composición suele funcionar en los navegadores, puede haber varios de estos registros por registro de subproceso del procesador, por lo que puedes usar sourceFrameNumber para vincularlos. También se discute si debería haber tiempo de CPU en estos registros, por lo que si sientes que estás al tanto de los problemas de GitHub.

Más información

Esta API aún no se está enviando, pero esperamos que lo haga pronto. Mientras tanto, aquí encontrarás algunas cosas que puedes leer y hacer: