will-change en CSS : prévenir le navigateur avant une animation coûteuse

Sur une animation complexe, un défilement légèrement saccadé ou une transformation qui met un instant à démarrer trahit souvent un navigateur pris au dépourvu, en train de préparer une optimisation au moment même où l'animation commence plutôt qu'avant. C'est exactement le problème que will-change cherche à résoudre.

Elle fonctionne comme un avertissement donné au navigateur, l'informant qu'une propriété va bientôt changer afin qu'il se prépare en amont. Bien utilisée, elle peut rendre une animation nettement plus fluide. Mal utilisée, posée un peu partout par réflexe, elle produit l'effet inverse.

Définition

will-change indique au navigateur qu'une ou plusieurs propriétés CSS d'un élément vont probablement changer prochainement, par exemple via une transition ou une Animation CSS. En le sachant à l'avance, le navigateur peut créer certaines optimisations en coulisses, comme placer l'élément sur son propre calque graphique, avant que le changement ne survienne réellement.

.carte-animee {
  will-change: transform;
}
.carte-animee:hover {
  transform: scale(1.05);
}

Les propriétés les plus fréquemment ciblées

will-change s'utilise le plus souvent avec transform et opacity, les deux propriétés les plus couramment animées et les plus sensibles aux optimisations de rendu. On peut cibler plusieurs propriétés à la fois, séparées par une virgule, ou utiliser les valeurs spéciales scroll-position et contents pour d'autres types de changements.

Le piège : une précaution qui coûte plus qu'elle ne rapporte

L'erreur la plus fréquente consiste à ajouter will-change à un grand nombre d'éléments par précaution, en se disant que cela ne peut pas faire de mal. C'est faux : chaque élément concerné par will-change peut recevoir son propre calque graphique dédié en mémoire, même s'il ne change jamais réellement. Sur une page avec des dizaines d'éléments ainsi marqués, la consommation de mémoire grimpe nettement, au point de ralentir la page entière plutôt que de l'accélérer.

will-change et les contextes d'empilement

Créer un nouveau calque graphique avec will-change crée aussi, comme effet de bord, un nouveau contexte d'empilement, ce qui peut modifier l'ordre d'affichage de certains éléments avec z-index à proximité. Ce détail explique parfois des superpositions inattendues sur une interface par ailleurs correctement construite.

will-change et le défilement

La valeur scroll-position vise un cas plus rare : un conteneur qui va bientôt défiler par programmation, par exemple lors d'un défilement fluide déclenché en JavaScript vers une section précise de la page. Elle prépare le navigateur à ce mouvement interne, exactement comme transform le prépare à une animation visuelle, mais reste beaucoup moins utilisée en pratique que transform et opacity. Elle se réserve aux cas où un défilement JavaScript coûteux provoque un ralentissement mesurable, pas par défaut sur un simple conteneur avec overflow: auto.

Questions fréquentes

Non, surtout pas systématiquement. will-change se réserve aux animations réellement coûteuses ou perceptiblement saccadées, pas à chaque petit effet de survol : sur des transformations simples et courtes, le navigateur optimise déjà très bien sans indication supplémentaire.

Non, ce n'est qu'un indice donné au navigateur, pas une garantie. Le navigateur reste libre de l'ignorer, notamment s'il juge que trop de calques dédiés existent déjà, et un JavaScript trop lourd exécuté en parallèle peut continuer à saccader l'animation malgré will-change.

Il vaut mieux le retirer une fois l'animation terminée, généralement via JavaScript à l'écoute de l'événement de fin de transition ou d'animation, plutôt que de le laisser indéfiniment, ce qui immobiliserait un calque graphique en mémoire sans raison une fois l'effet passé.