Feedback degli sviluppatori necessario - API Frame Timing

Paul Lewis
Twitter Homepage

Negli ultimi anni i browser hanno fatto passi da gigante in termini di prestazioni del rendering, in particolare sui dispositivi mobili. Mentre in precedenza non avevi alcuna speranza di ottenere una frequenza fotogrammi fluida per qualsiasi cosa remotamente complessa, oggi è almeno realizzabile se ci si prende cura di sé.

Per la maggior parte di noi, tuttavia, c'è una discrepanza tra ciò che possiamo ragionevolmente testare sui nostri dispositivi e l'esperienza dei nostri utenti. Se non ottengono 60 fps fluidi come la seta, la loro esperienza è compromessa e alla fine andranno altrove e noi ne soffriremo. Inoltre, il W3C sta parlando di una nuova API che potrebbe aiutarci a capire ciò che vedono i nostri utenti: l'API Frame Timing.

Di recente, io e Jake Archibald abbiamo registrato una panoramica video dell'API, quindi se preferite guardarla anziché leggere, dai un'occhiata:

Utilizzi dell'API Frame Timing

Ci sono senza dubbio una serie di cose che puoi fare con l'API Frame Timing e, soprattutto, puoi misurare ciò che è importante per te e per il tuo progetto. Anche in questo caso, ecco alcune idee:

  • Monitoraggio dei fotogrammi al secondo (f/s) delle animazioni JavaScript e CSS.
  • Monitorando la fluidità degli scorrimenti della pagina (o magari l'efficace elenco a scorrimento infinito che possiedi).
  • Scalabilità automatica degli effetti del programma in base al carico attuale del dispositivo.
  • Test di regressione sulle metriche delle prestazioni di runtime.

L'elevator pitch

Ecco come si presenta attualmente l'API nella specifica: con questa API puoi ottenere dati sulla tempistica dei thread del renderer, dove JavaScript, gli stili e il layout vengono eseguiti. (Potresti aver sentito parlare del thread del renderer chiamato thread principale; si tratta della stessa cosa con un altro nome.)

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

Ciascuno dei record del thread del renderer che visualizzi sarà simile al seguente:

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

Ogni record è essenzialmente un oggetto che contiene un numero di frame univoco, un timestamp ad alta risoluzione dell'inizio del frame e un altro relativo al tempo di CPU utilizzato. Con un array di questi, puoi esaminare ciascuno dei valori di startTime e scoprire se il thread principale va a 60 fps. In pratica "il startTime di ogni frame sale in blocchi di circa 16 ms?"

Inoltre, ricevi anche cpuTime, così saprai se ti trovi bene entro il limite di 16 ms o se ti trovavi a corto di cavo. Se cpuTime si trova vicino al limite dei 16 ms, non c'è molto spazio per strumenti come la garbage collection e, con un utilizzo elevato della CPU, anche il consumo della batteria sarà superiore.

Oltre al thread del renderer, puoi eseguire il pull dei dati anche sulla temporizzazione dei thread del compositore, in cui vengono eseguite operazioni di pittura e composizione:

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

Ognuno di questi elementi restituisce anche un numero di frame di origine, che puoi utilizzare per ricollegare gli eventi del thread principale:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

A causa del modo spesso di compositing funziona nei browser, potrebbero esserci diversi di questi record per record del thread del renderer, quindi puoi usare il sourceFrameNumber per ricollegarli. Si discute anche dell'eventuale presenza di tempo di CPU anche in questi record, quindi se hai voglia di parlare con forza sulle problemi di GitHub.

Maggiori informazioni

Questa API non è ancora disponibile, ma si spera che lo faccia a breve. Nel frattempo, ecco alcune cose che puoi leggere e fare: