Les animations ne sont pas le problème

Quand je dis que je fais de l’éco-conception, on me répond souvent la même chose : « Donc des sites moches. » Ou, plus poliment : « Donc pas d’animations. »

C’est une confusion, et elle mérite d’être défaite, parce qu’elle décourage des gens qui auraient tout intérêt à alléger leur site.

Le mouvement lui-même ne coûte presque rien. Ce qui coûte, c’est la bibliothèque téléchargée pour le décrire, le recalcul de mise en page imposé au navigateur à chaque image, et le thread principal occupé pendant ce temps. Les timelines de défilement natives, disponibles depuis 2024, suppriment les trois : une révélation au défilement s’écrit en sept lignes de CSS, sans une ligne de JavaScript.

Ce qui coûte, ce n’est pas le mouvement

Une animation coûte trois choses, et il faut les distinguer.

Le code qui la décrit. Une bibliothèque d’animation généraliste pèse entre 25 et 70 Ko compressés. Elle est téléchargée, analysée et exécutée avant que la moindre animation ne démarre. Sur un site qui anime trois blocs au défilement, on paie une boîte à outils complète pour utiliser deux tournevis.

Le travail à chaque image. C’est le poste le plus coûteux, et le moins visible. Une animation pilotée en JavaScript recalcule des positions soixante fois par seconde, sur le thread principal - celui-là même qui doit répondre aux clics. C’est pour ça qu’un site très animé devient collant au scroll sur un téléphone qui a trois ans.

Ce qu’elle force le navigateur à refaire. Animer left, top, width ou margin déclenche un recalcul de mise en page à chaque image, pour toute la page. Animer transform et opacity n’en déclenche aucun : ces deux propriétés sont traitées par le compositeur, sur une couche séparée, souvent sur le processeur graphique.

Le mouvement en lui-même ne coûte rien. Ce sont ces trois postes qui coûtent, et on peut les réduire à presque zéro sans renoncer à une seule animation.

Peut-on animer au défilement sans JavaScript ?

Depuis 2024, les navigateurs savent lier une animation CSS à la position de défilement, sans une ligne de JavaScript.

.bloc {
  animation: apparition linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 30%;
}

@keyframes apparition {
  from { opacity: 0; transform: translateY(2.5rem); }
  to   { opacity: 1; transform: none; }
}

Ces sept lignes remplacent le duo habituel IntersectionObserver + classe CSS, ou pire, l’écouteur scroll avec calcul de position. Trois différences pratiques :

• Rien ne tourne quand rien ne bouge. Un écouteur de défilement s’exécute même quand l’élément est hors champ. Une timeline de vue n’est évaluée que dans sa plage.
• Ça reste fluide quand la page travaille. L’animation vit sur le thread de composition. Un traitement JavaScript lourd ne la fait pas sauter.
• Ça se dégrade proprement. Encapsulé dans un @supports, l’effet disparaît sur les navigateurs qui ne le connaissent pas - et le contenu reste visible.

Ce dernier point est le plus important, et le plus souvent raté. Une révélation au défilement mal repliée, c’est une page blanche pour qui utilise un navigateur ancien. L’animation doit toujours être ce qu’on ajoute, jamais ce qui conditionne la lecture.

Là où JavaScript reste justifié

Je ne prétends pas que tout se fait en CSS. Trois cas où je prends encore du JavaScript :

• La physique. Un effet magnétique, un ressort, une inertie qui dépend de la vitesse du geste : CSS ne sait pas interpoler ça.
• La synchronisation de plusieurs éléments sur une même progression complexe, avec des décalages qui se recouvrent.
• Le dessin. Canvas, WebGL, particules. Le mouvement n’est plus une propriété de la page, c’est le contenu lui-même.

Dans ces cas-là, la question n’est pas « JavaScript ou pas », mais « combien ». Une animation sur mesure en quarante lignes bat une bibliothèque de 50 Ko à peu près à chaque fois, et le curseur de ce site en est un exemple : une seule boucle d’animation, qui s’arrête toute seule dès que la souris s’immobilise.

Le vrai arbitrage

Le budget d’une page est fini. Chaque kilo-octet dépensé quelque part n’est pas dépensé ailleurs.

La question utile n’est donc pas « est-ce que je peux me permettre cette animation ». C’est : qu’est-ce que je retire pour l’avoir ? Souvent, la réponse est facile - une photo de bandeau en 3000 pixels de large qu’on n’avait choisie que pour remplir, une police en six graisses dont on n’en affiche que deux, un lecteur de carte pour montrer une adresse qu’un lien vers l’application de cartographie afficherait mieux.

Retirez ça, et vous avez largement de quoi animer.

Et le confort de lecture

Un dernier point, qui n’est pas une question de poids. prefers-reduced-motion n’est pas une préférence esthétique : c’est un réglage que des personnes activent parce que le mouvement à l’écran leur donne des vertiges ou des migraines.

Le respecter ne demande presque rien. Sur ce site, les durées d’animation sont des variables CSS, et une seule règle les ramène toutes à une milliseconde quand le système le demande. Chaque composant devient sobre sans avoir eu à le prévoir.

C’est peut-être ça, au fond, l’éco-conception : moins une contrainte qu’une discipline qui rend le reste plus solide.