Animation CSS vs JavaScript : laquelle choisir pour votre site

Animation CSS vs JavaScript : usages, prise en main, limites et performance. Le comparatif clair pour choisir la bonne technique selon votre site et vos objectifs.

Animation CSS vs JavaScript : de quoi parle-t-on ?

Sur un site, une animation fait évoluer peu à peu une propriété visuelle : la position, l'opacité, la taille ou la couleur d'un élément. Le navigateur peut calculer ce mouvement seul, à partir d'une règle CSS, ou suivre les instructions d'un script. Le visiteur voit à peu près la même chose dans les deux cas. En revanche, l'écriture, la maintenance et le coût pour le navigateur ne sont pas les mêmes.

Tout se passe côté navigateur, c'est-à-dire dans la partie visible du site. Si la nuance vous échappe, notre article sur la différence entre front end et back end pose les bases. Une chose à garder en tête : une animation n'est pas une décoration. Bien utilisée, elle guide le regard, confirme une action et rassure le visiteur avant qu'il clique.

Les animations CSS : simples, déclaratives et légères

CSS propose deux outils. Les transitions animent le passage d'un état à un autre, par exemple la couleur d'un bouton au survol. Les animations à base de keyframes décrivent plusieurs étapes et peuvent tourner en boucle. Vous écrivez une règle dans la feuille de style et le navigateur s'occupe du reste, sans une ligne de script.

Pour quels usages ?

Le CSS est idéal pour les micro-interactions : un bouton d'appel à l'action qui réagit au survol, un menu qui se déplie, une carte qui se soulève légèrement. Il sert aussi aux indicateurs de chargement et aux apparitions discrètes de contenu. Ces effets courts et prévisibles représentent la grande majorité des besoins d'un site vitrine.

Les limites du CSS

Le CSS montre ses limites dès que l'animation doit dépendre de données ou d'événements complexes. Enchaîner de nombreuses étapes qui dépendent les unes des autres, suivre la souris au pixel près ou caler un mouvement sur le défilement demande vite des acrobaties. Les valeurs sont aussi écrites en dur dans la feuille de style, ce qui rend les réglages dynamiques difficiles.

  • Prise en main : rapide, accessible à tout intégrateur
  • Usages types : survols, menus, apparitions, chargements
  • Points forts : léger, aucune bibliothèque à charger, bonnes performances sur transform et opacity
  • Limites : enchaînements complexes, contrôle en temps réel, logique conditionnelle
  • Pour qui : la plupart des sites vitrines et des pages de conversion

Les animations JavaScript : contrôle total et pilotage en temps réel

Avec JavaScript, le script modifie le style d'un élément image après image. La méthode classique passe par une function appelée avec requestAnimationFrame, qui demande au navigateur de l'exécuter juste avant le prochain affichage. Par exemple, on sélectionne l'élément avec const box = document.querySelector('.box'), puis on met à jour box.style.transform à chaque image. Ce contrôle permet de réagir au geste du visiteur, à un calcul ou à une donnée reçue du serveur.

L'API Web Animations, un pont entre les deux

Il existe une voie médiane : the Web Animations API, souvent abrégée WAAPI. Elle reprend la logique des keyframes CSS, mais se pilote depuis un script avec la méthode animate(). On peut ainsi lancer, mettre en pause, inverser ou accélérer ses animations. L'API est intégrée aux navigateurs, sans fichier supplémentaire à charger.

Les bibliothèques comme GSAP

GSAP est une bibliothèque JavaScript très utilisée pour les animations ambitieuses : chronologies à plusieurs étapes, effets liés au défilement, animations de SVG. Elle fait gagner beaucoup de temps quand le projet est riche en mouvement. En échange, c'est une dépendance de plus à charger et à mettre à jour, et ses conditions d'utilisation sont à vérifier pour chaque projet.

  • Prise en main : plus technique, demande un développeur à l'aise avec JavaScript
  • Usages types : interfaces d'application, effets au défilement, animations interactives
  • Points forts : contrôle fin, enchaînements complexes, réaction au visiteur
  • Limites : plus de code à maintenir, risque de saccades si le script est mal écrit
  • Pour qui : applications web, sites événementiels, pages qui racontent une histoire

Performance : pourquoi le main thread change tout

Le navigateur fait l'essentiel de son travail sur un fil principal, le main thread : il y exécute les scripts, calcule la mise en page et traite les clics. Quand ce fil est saturé, l'animation saccade et la page répond mal. La documentation anglophone décrit ce problème par une formule courante : les animations ralentissent when the main thread is busy.

Certaines propriétés, surtout transform et opacity, peuvent être confiées à une autre partie du navigateur, le compositeur, qui tourne en dehors de the main thread. C'est vrai en CSS comme avec l'API Web Animations. À l'inverse, animer width, top ou margin force des recalculs coûteux, quel que soit l'outil. Ces choix pèsent sur la réactivité mesurée par les Core Web Vitals et sur la performance perçue par vos visiteurs.

Ressources pour aller plus loin

La plupart des références sont en anglais. Sur MDN, cherchez le guide « CSS and JavaScript animation performance » ou la page consacrée aux « CSS transitions and animations ». Pour la partie script, la requête « animations using requestAnimationFrame » mène à des exemples clairs. Retenez surtout le conseil qui revient partout : « you can animate transform and opacity in the browser compositor », c'est-à-dire en dehors du travail principal of the page.

Lequel choisir selon votre cas

Commencez toujours par le CSS, puis passez à JavaScript quand un besoin précis l'exige. Ce réflexe garde le code léger et facile à reprendre par un autre prestataire. Une bonne règle tirée des tutoriels : reach for JavaScript when you need real-time control, autrement dit dès que l'animation doit réagir au visiteur.

Vous avez un site vitrine ou une page de conversion

Le CSS suffit presque toujours. Des transitions sur les boutons, une apparition douce des sections et un menu fluide donnent une impression de qualité sans alourdir la page. Ici, gagner en vitesse rapporte plus qu'un effet spectaculaire.

Vous avez une application ou un outil métier

Les panneaux qui glissent, le glisser-déposer et les retours visuels liés aux données demandent souvent du JavaScript. L'API Web Animations couvre une bonne partie de ces besoins sans bibliothèque externe. Une bibliothèque comme GSAP se justifie surtout pour des parcours très animés.

Vous préparez un nouveau site et voulez trouver le bon dosage dès le départ ? C'est un sujet que nous traitons dès la maquette lors d'une création de site internet.

Questions fréquentes

Une transition anime le passage entre deux états, par exemple au survol ou quand une classe est ajoutée. Une animation CSS repose sur des keyframes : elle peut avoir plusieurs étapes, se répéter et démarrer sans action du visiteur. Pour un simple changement d'état, la transition suffit.

Pas forcément. Les animations sur transform et opacity restent fluides la plupart du temps. Ce qui ralentit une page, ce sont les propriétés qui forcent un nouveau calcul de mise en page, les scripts lourds et les bibliothèques chargées sans vraie raison.

Rarement. Pour un site vitrine classique, le CSS et éventuellement l'API Web Animations couvrent les besoins. GSAP devient intéressant quand le site repose sur des animations au défilement ou des enchaînements complexes.

À lire aussi. Sur le même thème.