Feedback degli sviluppatori necessario - API Frame Timing

Paul Lewis
X Home page

Negli ultimi anni i browser hanno fatto enormi passi avanti in termini di prestazioni di rendering, in particolare sui dispositivi mobili. Se in precedenza non avevi alcuna speranza di raggiungere un framerate fluido per qualsiasi cosa anche lontanamente complessa, oggi è almeno possibile se fai attenzione.

Per la maggior parte di noi, però, esiste una disconnessione tra ciò che possiamo ragionevolmente testare sui nostri dispositivi e ciò che sperimentano i nostri utenti. Se non ottengono una riproduzione fluida a 60 fps, la loro esperienza è compromessa e, alla fine, sceglieranno un'altra piattaforma, con conseguenze negative per noi. È un bene, quindi, che il W3C stia discutendo di una nuova API che potrebbe aiutarci a vedere 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 preferisci guardare piuttosto che leggere, dai un'occhiata:

Utilizzi dell'API Frame Timing

Senza dubbio, puoi fare molte cose con l'API Frame Timing e, soprattutto, puoi misurare ciò che è importante per te e per il tuo progetto. Tuttavia, ecco alcune idee:

  • Monitoraggio dei frame al secondo delle animazioni JavaScript e CSS.
  • Monitoraggio della fluidità dello scorrimento della pagina (o forse di quel fantastico elenco con scorrimento continuo).
  • Riduci automaticamente gli effetti di Spettacolo in base al carico corrente del dispositivo.
  • Test di regressione sulle metriche relative alle prestazioni di runtime.

L'elevator pitch

Ecco come appare attualmente l'API nella specifica: con questa API puoi estrarre i dati sui tempi del thread del renderer, dove vengono eseguiti JavaScript, stili e layout. Potresti aver sentito il thread del renderer chiamato thread principale; si tratta della stessa cosa con un altro nome.

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

Ogni record del thread del renderer che ricevi ha questo aspetto:

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

Ogni record è essenzialmente un oggetto che contiene un numero di fotogramma univoco, un timestamp ad alta risoluzione per l'inizio del fotogramma e un altro per la quantità di tempo della CPU utilizzata. Con un array di questi valori, puoi esaminare ciascuno dei valori startTime e scoprire se il thread principale funziona a 60 fps; in sostanza, "il valore startTime di ogni fotogramma aumenta in blocchi di circa 16 ms?"

Ma non solo: ottieni anche il valore cpuTime, che ti consente di sapere se sei comodamente entro il limite di 16 ms o se hai rischiato di non farcela. Se cpuTime è vicino al limite di 16 ms, non c'è molto spazio per cose come l'attivazione del garbage collection e, con un utilizzo elevato della CPU, anche il consumo della batteria sarà maggiore.

Oltre al thread del renderer, puoi anche estrarre i dati sulla temporizzazione del thread del compositore, dove vengono eseguiti la pittura e il compositing:

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

Ognuno di questi viene restituito anche con un numero di frame di origine, che puoi utilizzare per ricollegarti agli eventi del thread principale:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

A causa del modo in cui spesso funziona il compositing nei browser, potrebbero esserci diversi di questi record per record del thread del renderer, quindi puoi utilizzare sourceFrameNumber per riunirli. Inoltre, c'è qualche discussione sul fatto che anche in questi record debba essere presente il tempo CPU, quindi se ritieni che sia importante, parla dei problemi di GitHub.

Ulteriori informazioni

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