Ces dernières années, les navigateurs ont énormément progressé en termes de performances d'affichage, en particulier sur mobile. Alors qu'auparavant vous n'aviez aucun espoir d'atteindre une fréquence de frames fluide pour quelque chose de très complexe, aujourd'hui, c'est au moins réalisable si vous prenez soin de vous.
Pour la plupart d'entre nous, cependant, 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'atteignent pas une fréquence d'images de 60 images par seconde, leur expérience est altérée. À terme, ils iront voir ailleurs et nous en souffrons. Par ailleurs, le W3C est en train de discuter d'une nouvelle API qui pourrait nous aider à voir ce que nos utilisateurs voient: l'API Frame Timing.
Avec Jake Archibald, nous avons récemment enregistré une vidéo de présentation de l'API. Si vous préférez, vous pouvez regarder la suite:
Utilisations de l'API Frame Timing
L'API Frame Timing vous permet sans aucun doute de faire tout un tas de choses. Plus important encore, vous pouvez mesurer ce qui est important pour vous et pour votre projet. Malgré tout, voici quelques idées:
- Suivi du FPS de vos animations JavaScript et CSS.
- Suivre la fluidité des défilements de votre page (ou peut-être la superbe liste à défilement infini que vous avez).
- Réduit automatiquement la réduction de vos effets Showbiz en fonction de la charge actuelle de l'appareil.
- Tests de régression sur les métriques de performances d'exécution
L'elevator pitch
Voici à quoi ressemble actuellement l'API dans la spécification: elle vous permet d'extraire des données sur la durée 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é le thread principal ; c'est la même chose sous un autre nom.)
var rendererEvents = window.performance.getEntriesByType("renderer");
Chacun des enregistrements de thread de moteur 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 horodatage haute résolution correspondant au début de la trame et un autre indiquant le temps CPU utilisé. Avec un tableau de celles-ci, vous pouvez examiner chacune des valeurs startTime
et déterminer si le thread principal fonctionne à 60 FPS. Autrement dit, "le startTime
de chaque image augmente-t-il par blocs d'environ 16 ms ?".
Mais ce n'est pas tout : vous obtenez également la valeur cpuTime
. Vous savez donc si vous êtes confortablement dans la limite de 16 ms ou si vous êtes bien au bout du fil. Si cpuTime
se trouve tout près de la limite de 16 ms, il n'y a pas beaucoup de place pour des éléments tels que la récupération de mémoire. Lorsque l'utilisation du processeur est élevée, l'utilisation de la batterie sera également plus élevée.
En plus du thread du moteur de rendu, vous pouvez également extraire des données sur la durée du thread du compositeur, qui implique la peinture et la composition:
var compositeThreadEvents = window.performance.getEntriesByType("composite");
Chacun d'eux renvoie également 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
}
Étant donné que la composition fonctionne souvent dans les navigateurs, il peut y avoir plusieurs de ces enregistrements par enregistrement de thread de moteur de rendu. Vous pouvez donc utiliser sourceFrameNumber
pour les relier les uns aux autres. La question de savoir si ces enregistrements doivent également contenir du temps CPU est une question. Si vous êtes d'accord, n'hésitez pas à signaler les problèmes GitHub.
Plus d'informations
Cette API n'est pas encore disponible, mais nous espérons qu'elle le sera bientôt. En attendant, voici quelques contenus que vous pouvez lire et faire:
- Consultez le document d'explication dans le dépôt. Il existe de nombreuses nuances quant à la manière dont vous devez enregistrer au mieux les données de trame pour qu'elles soient significatives, et l'explication donne une indication ici.
- Consultez la dernière version préliminaire de la spécification. Elle est assez légère et vaut la peine d'être lue.
- Signalez des fonctionnalités manquantes ou des problèmes potentiels. Comme vous savez ce que vous voulez mesurer, n'hésitez pas à nous faire part de vos commentaires si vous pensez que certaines actions ne sont pas possibles avec l'API.