Des animations au scroll sans tuer la perf

Animer n'oblige pas à ralentir, à condition de choisir les bonnes propriétés

Une animation fluide repose sur le choix des propriétés CSS animées, pas sur la puissance du téléphone. Seules transform et opacity peuvent être traitées par le compositeur du navigateur, sans recalculer la mise en page ni repeindre la page. Animer la position, la largeur, la hauteur ou les marges force au contraire le navigateur à tout recalculer image après image, et c'est là que ça rame.

Ma règle de base est simple : pour bouger un élément, j'utilise transform: translate, pour le faire apparaître j'utilise opacity, pour l'agrandir transform: scale. Jamais top, left, width ou height dans une animation au scroll. Cette seule discipline suffit à éliminer la majorité des ralentissements que je vois sur les sites buildés à la va-vite.

IntersectionObserver plutôt que l'écoute du scroll

Pour déclencher une animation quand un élément entre dans l'écran, IntersectionObserver bat l'écoute de l'événement scroll dans tous les cas. L'événement scroll se déclenche des dizaines de fois par seconde et exécute mon code à chaque fois, ce qui sature le thread principal et fait sauter le défilement. IntersectionObserver, lui, prévient seulement quand un élément franchit un seuil, sans ce coût permanent.

Concrètement, j'observe les éléments à animer et j'ajoute une classe quand ils deviennent visibles, classe qui déclenche une transition CSS. Le navigateur fait le gros du travail de manière optimisée, et mon JavaScript reste minimal. Cette approche tient même sur des pages longues avec des dizaines d'éléments animés, là où une écoute du scroll s'effondrerait.

Si j'ai besoin d'une animation liée à la progression du scroll, et non à un simple déclenchement, je regarde d'abord du côté des animations pilotées par le scroll en CSS natif quand le support le permet. Elles s'exécutent hors du thread principal, ce qui garde l'interface réactive même pendant l'effet.

Respecter prefers-reduced-motion n'est pas optionnel

Respecter prefers-reduced-motion est une obligation d'accessibilité, pas une finition cosmétique. Certaines personnes désactivent les animations parce que le mouvement leur donne la nausée, déclenche des migraines ou des troubles vestibulaires. Ignorer ce réglage système, c'est rendre une page pénible voire inutilisable pour ces visiteurs, et c'est facile à éviter.

Je gère ce cas avec une media query qui coupe ou réduit fortement les animations quand l'utilisateur l'a demandé. Le contenu reste présent et lisible, simplement il apparaît sans mouvement. Un élément censé surgir s'affiche directement à sa place finale, sans transition. Rien n'est perdu, le confort est gagné.

Cette précaution profite aussi à la perception générale de qualité. Un site qui respecte les préférences de l'utilisateur envoie un signal de soin et de sérieux. C'est exactement l'attention que mérite le visiteur, qu'il soit gêné par le mouvement ou simplement de passage sur un vieux téléphone.

Mesurer sur un vrai téléphone, pas sur ma machine

Une animation se valide sur un appareil modeste, jamais sur la machine du développeur. Mon ordinateur masque tous les problèmes : il a la puissance pour absorber des animations mal écrites qui feront ramer un téléphone d'entrée de gamme. Tester uniquement sur son poste, c'est livrer un site fluide pour soi et saccadé pour la moitié des visiteurs.

J'utilise le throttling CPU des outils de développement pour simuler un appareil lent, et je teste sur un vrai téléphone quand c'est possible. Je surveille l'INP et la fluidité du défilement, pas seulement le rendu visuel. Une animation peut sembler jolie tout en faisant grimper le temps de réponse aux interactions, ce qui dégrade l'expérience et les Core Web Vitals.

Doser pour servir le contenu, pas l'inverse

Une animation utile guide le regard et hiérarchise l'information, une animation décorative finit par fatiguer. La meilleure animation est souvent celle qu'on ne remarque pas consciemment : une apparition douce qui signale qu'une section commence, un léger décalage qui crée du rythme. Quand chaque bloc bouge dans tous les sens, plus rien ne ressort et la page devient bruyante.

Je garde donc les effets courts, autour de 200 à 400 millisecondes, avec des courbes d'accélération naturelles. Pas d'animation au-delà du nécessaire, surtout pas sur des éléments critiques comme un bouton d'appel ou un numéro de téléphone, qui doivent être disponibles tout de suite. L'animation est au service du message du client, pas l'inverse, et c'est cette retenue qui sépare un site vivant d'un site épuisant.