Animer un site sans le ralentir

Un titre qui se pose, des photos qui glissent à leur arrivée, un fond qui respire : une page animée retient l’œil. Elle peut aussi devenir lente, saccader, ou sauter sous le doigt au moment où l’on vise un bouton. La différence tient à quelques choix techniques, toujours les mêmes.

Les voici, avec ce que Google mesure. Il le précise lui-même : la pertinence du contenu passe en premier, et une bonne expérience de page peut aider à départager des pages également utiles (Google Search Central, 2026).

Ce que le navigateur anime sans effort

Pour afficher une page, le navigateur fait trois choses : il calcule la place de chaque élément (la mise en page), il dessine les pixels (la peinture), puis il assemble les calques (la composition). Une animation qui touche à la mise en page refait les trois étapes à chaque image ; une animation qui ne touche qu’à la composition saute les deux premières.

web.dev le résume : animez transform et opacity, et évitez ce qui déclenche la mise en page ou la peinture. En pratique :

pour faire glisser un élément, déplacez-le avec transform (translate), plutôt qu’en changeant top ou left ;
pour le grossir, utilisez transform (scale), plutôt que sa largeur et sa hauteur ;
pour le faire apparaître, jouez sur opacity ;
évitez d’animer une ombre portée : elle oblige le navigateur à repeindre à chaque image (web.dev).

La propriété will-change prépare un élément à bouger, mais crée un calque qui a lui aussi un coût. web.dev conseille de ne s’en servir qu’en cas de problème constaté.

Le travers est répandu : 40 % des pages mobiles contiennent au moins une animation « non composée », qui ne peut pas se contenter de la composition (Web Almanac 2025).

Ne rien faire sauter : le CLS

Le Cumulative Layout Shift (CLS) mesure les éléments qui se déplacent sans que le visiteur l’ait demandé : le paragraphe qui descend pendant qu’on le lit, le bouton qui fuit sous le doigt. Google le juge bon à 0,1 ou moins, mauvais au-delà de 0,25, quand trois visites sur quatre atteignent le seuil (le 75e centile, web.dev). 81 % des sites atteignent le bon seuil sur mobile (Web Almanac 2025).

Les animations y entrent par trois portes :

Changer top, left, la largeur ou la hauteur d’un élément le déplace, pousse souvent ses voisins, et compte comme un décalage. Une animation avec transform, elle, ne compte pas (web.dev).
Faire apparaître un bloc qui n’avait pas de place réservée : un bandeau en haut de page, une image sans dimensions. Réservez la place à l’avance, avec la largeur et la hauteur de l’image ou un rapport d’aspect.
Animer pendant le défilement. Les décalages qui surviennent moins d’une demi-seconde après un clic, un toucher ou une touche du clavier sont pardonnés ; le défilement n’en fait pas partie. Un bloc qui grandit quand on fait défiler la page compte donc en plein.

La règle tient en une phrase : un élément qui apparaît le fait à sa place, en fondu ou en glissant avec transform, sans changer de taille.

Répondre vite : l’INP

L’Interaction to Next Paint (INP) mesure le temps entre un clic, un toucher ou une touche et l’image suivante à l’écran, sur toute la visite. Google le juge bon à 200 millisecondes ou moins, mauvais au-delà de 500 (web.dev).

Le coupable habituel est le fil principal du navigateur, celui qui exécute le JavaScript et répond aux gestes. Occupé par de longues tâches, il fait attendre la réponse quand le visiteur touche un bouton (web.dev). Un script qui recalcule la position de chaque élément à chaque mouvement de molette, pour savoir quoi animer, en est l’exemple classique. MDN le rappelle : ces calculs tournent sur le fil principal, et une seule de ces routines peut suffire à ralentir la page.

Pour déclencher une animation quand un élément entre à l’écran, l’API Intersection Observer prévient le script au bon moment, sans le faire travailler à chaque mouvement (MDN).

Le téléphone est le vrai terrain d’essai : 97 % des sites ont un bon INP sur ordinateur, 77 % seulement sur mobile (Web Almanac 2025). Testez sur un téléphone modeste, en plus du vôtre.

Les animations au défilement en CSS

Le CSS sait désormais lier une animation au défilement, sans une ligne de JavaScript. La propriété animation-timeline accepte deux repères (MDN) :

scroll() suit la progression dans la page : une barre de lecture qui se remplit, un fond qui change de teinte ;
view() suit le passage d’un élément dans l’écran : une photo qui se dévoile en entrant, un titre qui se pose.

Leur intérêt est la fluidité. Chrome a comparé une barre de progression écrite en JavaScript et la même en CSS, sous une lourde charge : la version JavaScript saccadait, la version CSS suivait le défilement (Chrome for Developers, 2023).

Leur limite est la prise en charge. Au 22 octobre 2026, MDN les classe encore en disponibilité limitée : Chrome et Edge les gèrent depuis juillet 2023, Safari depuis sa version 26 de septembre 2025, et Firefox les prépare (sa version 159, d’après les données de compatibilité de MDN). Traitez-les comme un bonus :

la page doit être complète et lisible sans elles ;
testez la prise en charge avec @supports avant de les appliquer ;
placez-les sous la condition prefers-reduced-motion: no-preference, pour respecter les visiteurs qui ont demandé moins d’animations (voir le mouvement accessible).

La vidéo plutôt que le GIF

Le GIF animé est un format ancien et lourd. Dans l’exemple de web.dev, un GIF de 3,7 Mo devient une vidéo MP4 de 551 Ko, ou WebM de 341 Ko, pour la même animation. Une vidéo courte qui se joue seule, en boucle, sans son et dans la page reproduit l’effet du GIF pour une fraction du poids.

Pour un fond vidéo, quelques règles de plus :

une affiche, l’image fixe affichée avant le film. Pour une vidéo, Google retient pour le Largest Contentful Paint le premier des deux moments : l’affiche chargée ou la première image du film, et il juge bon un affichage en 2,5 secondes au plus (web.dev) ;
pas de piste son : un fond n’en a pas besoin ;
une largeur adaptée à l’écran qui la reçoit, et un encodage soigné ;
une boucle courte, discrète, qui ne se bat pas avec le titre.

Tester avant de publier

Les outils de développement de Chrome montrent ce qui coûte : le panneau Performance enregistre l’animation, l’affichage des zones repeintes révèle ce qui se redessine, et le compteur d’images signale les images perdues (web.dev). Ralentissez le processeur dans ces outils pour voir la page comme un téléphone d’entrée de gamme.

Les seuils de Google se mesurent sur de vraies visites, au 75e centile : un test sur votre ordinateur donne une première idée, et le verdict vient de vos visiteurs. Le détail des trois mesures est dans notre article sur les Core Web Vitals.

Dans l’atelier de 29webs, la vidéo de fond est réencodée et allégée, sans piste son, et accompagnée d’une affiche ; elle s’efface si le visiteur a demandé moins d’animations, et l’affiche reste.

En résumé : animez transform et opacity, réservez la place de ce qui arrive, laissez le fil principal libre pour les clics, et gardez les animations au défilement en CSS comme un bonus. Remplacez les GIF par de la vidéo, et donnez toujours une affiche à un fond animé.