Un audit de thème WordPress a révélé une feuille de style contenant la règle * { will-change: transform, opacity; }, appliquée globalement à tous les éléments du site par un développeur cherchant, en théorie, à fluidifier l’ensemble des transitions CSS du thème.
Ce qu’on observe ici est un antipattern assez répandu : partant du principe qu’will-change accélère les animations, la règle est appliquée le plus largement possible, par précaution, sans mesurer l’effet réel sur les éléments qui n’ont jamais d’animation ni de transition.
Pourquoi c’est un problème
will-change indique au navigateur qu’un élément va probablement changer d’une manière qui bénéficierait d’une optimisation anticipée, généralement en créant une couche de composition séparée pour cet élément, gérée directement par le processeur graphique plutôt que recalculée à chaque image par le moteur de mise en page classique. Cette couche occupe de la mémoire vidéo, même si l’élément ne change jamais réellement d’état.
Sur un site comportant plusieurs centaines d’éléments visibles dans le DOM d’une page complexe, appliquer will-change à tous crée autant de couches de composition séparées, ce qui peut, sur des appareils mobiles à mémoire graphique limitée, ralentir l’ensemble du rendu au lieu de l’accélérer, un effet contraire à l’intention initiale.
Ce qu’on constate en pratique
- Un défilement de page devenu perceptiblement saccadé sur un téléphone d’entrée de gamme, alors que le même thème sans la règle globale défilait sans accroc.
- Une consommation mémoire GPU visible dans l’onglet Rendu des outils de développement, largement supérieure à ce que les animations réelles du site justifieraient.
- Aucune amélioration mesurable sur les animations elles-mêmes, celles-ci bénéficiant déjà d’une accélération suffisante via les propriétés
transformetopacityseules, sanswill-changeajouté en permanence.
Le bon usage : ciblé et temporaire
.carte-produit {
transition: transform 0.2s ease;
}
.carte-produit:hover {
will-change: transform;
transform: translateY(-4px);
}
Ici, will-change n’est déclaré que sur l’état :hover, c’est-à-dire seulement au moment où l’animation est sur le point de se produire. Le navigateur crée la couche de composition juste avant que l’utilisateur ne survole la carte, et peut la libérer une fois l’interaction terminée, plutôt que de la maintenir en permanence pour un élément qui reste statique la majorité du temps.
Une alternative encore plus ciblée en JavaScript
Pour une animation déclenchée par script plutôt que par un pseudo-état CSS, il est possible d’ajouter la propriété juste avant de démarrer l’animation, puis de la retirer explicitement une fois celle-ci terminée, via l’écouteur d’événement transitionend, pour ne jamais laisser la couche de composition active plus longtemps que nécessaire.
Ce qu’il faut retenir avant d’utiliser cette propriété
- Réserver
will-changeaux éléments effectivement animés, jamais à un sélecteur global. - La déclarer au plus près du déclenchement de l’animation, pas dès le chargement de la page.
- La retirer une fois l’animation terminée si elle a été ajoutée dynamiquement.
- Mesurer la consommation mémoire GPU avant et après tout ajout massif, via l’onglet Rendu des outils de développement.
Comment repérer ce problème sur un thème existant
L’onglet Rendu des outils de développement d’un navigateur basé sur Chromium propose une option pour visualiser directement les couches de composition actives sur la page, souvent nommée « Layer borders ». Sur le site audité, activer cette option révélait des centaines de rectangles superposés couvrant la quasi-totalité de la page, un signe immédiatement visible d’un usage démesuré de will-change avant même d’ouvrir la feuille de style pour en confirmer la cause.
Une méthode simple pour auditer une feuille de style existante
grep -rn "will-change" wp-content/themes/mon-theme/
Cette commande, exécutée directement sur les fichiers source du thème, permet de repérer en quelques secondes chaque occurrence de la propriété, et de vérifier pour chacune si le sélecteur ciblé correspond bien à un élément réellement animé, plutôt qu’à une règle globale ou à un sélecteur trop large hérité d’une copie de code non relue.
En résumé
L’usage préventif et généralisé de will-change transforme une optimisation ciblée en un gaspillage de ressources graphiques, avec un effet parfois inverse à l’objectif recherché. La règle à retenir reste simple : cette propriété se mérite, elle ne se distribue pas par précaution à l’ensemble d’un thème.
