Commentaires des développeurs requis : API Frame Timing

Au cours des dernières années, les navigateurs ont fait d'énormes progrès en termes de performances de rendu, en particulier sur mobile. Là où vous n'aviez aucun espoir d'atteindre un framerate fluide pour tout élément complexe, il est aujourd'hui au moins possible d'y parvenir si vous y prenez garde.

Cependant, pour la plupart d'entre nous, il existe un décalage entre ce que nous pouvons raisonnablement tester sur nos propres appareils et ce que nos utilisateurs vivent. S'ils n'obtiennent pas une expérience fluide à 60 FPS, leur expérience est dégradée, et ils iront voir ailleurs, ce qui nous pénalisera. Il est donc heureux que le W3C discute d'une nouvelle API qui pourrait nous aider à voir ce que nos utilisateurs voient: l'API Frame Timing.

Jake Archibald et moi-même avons récemment enregistré une vidéo de présentation de l'API. Si vous préférez regarder une vidéo plutôt que de lire un article, regardez-la:

Utilisations de l'API Frame Timing

Vous pouvez sans aucun doute faire de nombreuses choses avec l'API Frame Timing. Et surtout, vous pouvez mesurer ce qui est important pour vous et pour votre projet. Voici quelques idées:

  • Suivre les FPS de vos animations JavaScript et CSS
  • Suivre la fluidité du défilement de vos pages (ou de votre liste à défilement infini)
  • Ajustement automatique de vos effets de scène en fonction de la charge actuelle de l'appareil.
  • Tests de régression sur les métriques de performances d'exécution

Elevator pitch

Voici à quoi ressemble actuellement l'API dans la spécification: elle vous permet d'extraire des données sur le timing du thread du moteur de rendu, où JavaScript, les styles et la mise en page s'exécutent. (Vous avez peut-être entendu le thread du moteur de rendu appelé "thread principal". Il s'agit de la même chose sous un autre nom.)

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

Chaque enregistrement de thread de rendu que vous obtenez se présente à peu près comme suit:

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

Chaque enregistrement est essentiellement un objet contenant un numéro de frame unique, un code temporel haute résolution pour le début du frame et un autre pour la durée de CPU utilisée. Avec un tableau de ces valeurs, vous pouvez examiner chacune des valeurs startTime et déterminer si le thread principal fonctionne à 60 FPS. En d'autres termes, "le startTime de chaque frame augmente-t-il par blocs d'environ 16 ms ?"

Mais vous obtenez également cpuTime, ce qui vous permet de savoir si vous êtes confortablement dans la limite de 16 ms ou si vous avez été au bout du fil. Si cpuTime est proche de la limite de 16 ms, il n'y a pas beaucoup de place pour des éléments tels que le déclenchement du garbage collection. De plus, avec une utilisation élevée du processeur, la consommation de la batterie sera également plus élevée.

En plus du thread du moteur de rendu, vous pouvez également extraire des données sur le timing du thread du moteur de composition, où la peinture et le compositing ont lieu:

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

Chacun d'eux est également associé à un numéro de frame source, que vous pouvez utiliser pour faire le lien avec les événements du thread principal:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

En raison de la façon dont la composition fonctionne souvent dans les navigateurs, il peut y avoir plusieurs de ces enregistrements par enregistrement de thread de rendu. Vous pouvez donc utiliser sourceFrameNumber pour les associer. Il est également question de savoir si le temps de processeur doit également figurer dans ces enregistrements. Si vous avez un avis tranché, n'hésitez pas à nous en faire part dans les problèmes GitHub.

En savoir plus

Cette API n'est pas encore disponible, mais nous espérons qu'elle le sera bientôt. En attendant, voici quelques articles et actions que vous pouvez consulter et effectuer: