Les animations doivent être performantes, sans quoi elles auront un impact négatif sur l'expérience utilisateur.
Maintenez une fréquence de 60 images par seconde chaque fois que vous créez une animation. Au-delà de cette limite, vous risquez de provoquer des saccades ou des blocages que les utilisateurs pourront remarquer et qui auront un impact négatif sur leur expérience.
- Assurez-vous que vos animations ne causent pas de problèmes de performances et que vous connaissez l'impact de l'animation d'une propriété CSS donnée.
- Les propriétés d'animation qui modifient la géométrie de la page (mise en page) ou qui entraînent l'application de peinture sont particulièrement coûteuses.
- Lorsque c'est possible, tenez-en à la modification de l'opacité et des transformations.
- Utilisez
will-changepour vous assurer que le navigateur sait ce que vous prévoyez d'animer.
L'animation des propriétés n'est pas sans frais, et certaines propriétés sont moins chères à animer que d'autres. Par exemple, l'animation des éléments width et height d'un élément modifie sa géométrie et peut déplacer les autres éléments de la page ou leur taille. Ce processus est appelé mise en page (ou ajustement de la mise en page dans les navigateurs Gecko tels que Firefox). Il peut être coûteux si la page contient de nombreux éléments. Chaque fois que la mise en page est déclenchée, la page ou une partie de celle-ci doit normalement être peinte, ce qui est généralement plus coûteux que l'opération de mise en page elle-même.
Dans la mesure du possible, évitez d'animer des propriétés qui déclenchent la mise en page ou l'affichage. Pour la plupart des navigateurs récents, cela implique de limiter les animations à opacity ou transform, deux éléments que le navigateur peut fortement optimiser. Peu importe si l'animation est gérée par JavaScript ou CSS.
Lisez notre guide complet sur la création d'animations hautes performances.
Utiliser la propriété will-change
Utilisez will-change pour vous assurer que le navigateur sait que vous souhaitez modifier la propriété d'un élément. Le navigateur peut ainsi mettre en place les optimisations les plus appropriées avant le moment où vous effectuez la modification. Toutefois, n'abusez pas de will-change, car cela pourrait gaspiller des ressources par le navigateur, ce qui entraînerait encore plus de problèmes de performances.
En règle générale, si l'animation peut être déclenchée dans les 200 ms suivantes, soit par l'interaction d'un utilisateur, soit à cause de l'état de l'application, il est recommandé d'utiliser will-change sur l'animation des éléments. Dans la plupart des cas, will-change doit être activé pour tout élément de la vue actuelle de votre application que vous souhaitez animer, quelles que soient les propriétés que vous prévoyez de modifier. Dans le cas de l'exemple "box" que nous avons utilisé dans les guides précédents, l'ajout de will-change pour les transformations et l'opacité se présente comme suit:
.box {
will-change: transform, opacity;
}
Désormais, les navigateurs compatibles (actuellement les navigateurs les plus récents) apporteront les optimisations appropriées en arrière-plan pour permettre la modification ou l'animation de ces propriétés.
Performances CSS et JavaScript
De nombreux fils de discussion et pages de commentaires sur le Web abordent les avantages relatifs des animations CSS et JavaScript du point de vue des performances. Voici quelques points à retenir:
Les animations basées sur CSS et les animations Web, lorsqu'elles sont compatibles de manière native, sont généralement gérées sur un thread appelé "thread compositeur". Il est différent du "thread principal du navigateur", où les styles, la mise en page, la peinture et JavaScript sont exécutés. Cela signifie que si le navigateur exécute des tâches coûteuses sur le thread principal, ces animations peuvent continuer sans être interrompues.
Dans de nombreux cas, d'autres modifications apportées aux transformations et à l'opacité peuvent également être gérées par le thread compositeur.
Si une animation déclenche l'affichage, la mise en page ou les deux, le "thread principal" sera nécessaire. Cela est vrai pour les animations basées sur CSS et JavaScript. Les frais généraux liés à la mise en page ou au dessin risquent d'éclipser tout travail associé à l'exécution CSS ou JavaScript, rendant ainsi la question moot.