Animations CSS scroll-driven en 2026 : fluides, sans JavaScript
Découvrez les animations CSS scroll-driven en 2026 : créez des effets fluides au défilement sans JavaScript grâce à animation-timeline, scroll() et :has().
Sommaire
Les animations CSS scroll-driven permettent en 2026 de lier un effet au défilement de la page sans une seule ligne de JavaScript, grâce à animation-timeline, scroll() et view().
Pendant des années, ces effets exigeaient une librairie comme GSAP ou un IntersectionObserver maison. Désormais, le navigateur fait le travail nativement. Chez ConsilioWEB, agence web à Ussel en Corrèze, nous avons basculé notre propre design system sur cette approche. Le gain est net : moins de code, des animations plus fluides, une meilleure performance. Si vous hésitez à moderniser votre site, demandez un audit technique gratuit à notre équipe.
Le scroll-driven natif arrive en 2026
Les animations CSS scroll-driven reposent sur une idée simple : utiliser la position du scroll comme « ligne de temps » d'une animation. Au lieu de déclencher un effet après un délai fixe, vous le pilotez avec le défilement.
Concrètement, une animation classique progresse seule, de 0 à 100 %, selon une durée. Une animation pilotée par le scroll progresse, elle, au rythme exact de l'utilisateur. La barre de progression en haut d'un article en est l'exemple typique.
D'abord réservée aux navigateurs Chromium, la fonctionnalité est aujourd'hui largement disponible. En 2026, Chrome, Edge, Firefox et Safari supportent les animations CSS scroll-driven, ce qui change la donne pour la production.
Deux nouvelles fonctions structurent tout : scroll() et view(). La première suit le défilement d'un conteneur. La seconde suit l'entrée et la sortie d'un élément dans la fenêtre. Ensemble, elles couvrent l'immense majorité des besoins.
Maîtriser scroll() et view()
La fonction animation-timeline accepte une timeline anonyme renvoyée par scroll() ou view(). Voici une barre de progression liée au défilement vertical de la page.
1@keyframes grow-progress {2 from { transform: scaleX(0); }3 to { transform: scaleX(1); }4}56.progress-bar {7 transform-origin: left;8 animation: grow-progress linear;9 animation-timeline: scroll(root block);10}
Aucun JavaScript. Le navigateur calcule la progression sur le thread compositeur, ce qui garantit une fluidité constante, même sur mobile d'entrée de gamme.
Comment révéler un élément au scroll ?
C'est ici que view() brille. Cette fonction crée une timeline basée sur la visibilité d'un élément dans la fenêtre. Par exemple, faire apparaître une carte quand elle entre à l'écran devient trivial.
1@keyframes fade-in {2 from { opacity: 0; transform: translateY(40px); }3 to { opacity: 1; transform: translateY(0); }4}56.card {7 animation: fade-in linear both;8 animation-timeline: view();9 animation-range: entry 0% cover 40%;10}
La propriété animation-range est centrale. Elle définit quand l'animation démarre et se termine par rapport à la position de l'élément. Ainsi, vous contrôlez finement la fenêtre d'apparition sans aucun observateur d'intersection.
Voici les valeurs de animation-range que nous utilisons le plus souvent :
entry: pendant l'entrée de l'élément dans la fenêtre.exit: pendant sa sortie, idéal pour un effet de fondu.cover: tant que l'élément chevauche la fenêtre.contain: tant qu'il est entièrement visible.
Ces effets de révélation rejoignent l'esprit des micro-interactions qui améliorent l'UX sans alourdir la page. Bien dosés, ils guident l'œil et rythment la lecture.
Le sélecteur :has() en pratique
Le sélecteur :has() complète parfaitement les animations CSS scroll-driven. Il agit comme un sélecteur de parent : une règle s'applique à un élément selon ce qu'il contient. Cela permet de réagir à un état sans JavaScript.
Imaginons un menu de navigation qui doit se compacter quand un panneau latéral est ouvert. Auparavant, il fallait basculer une classe via JavaScript. Désormais, :has() suffit.
1/* Le header se réduit quand un dialogue est ouvert */2body:has(dialog[open]) .site-header {3 transform: scale(0.95);4 transition: transform 0.3s ease;5}
En revanche, :has() ne pilote pas le scroll lui-même. Il gère les états ; scroll() et view() gèrent le défilement. Combinés, ils remplacent une bonne partie du JavaScript d'interface que nous écrivions encore en 2024.
Par exemple, on peut styliser un formulaire selon la validité de ses champs, ou changer une grille selon le nombre d'éléments présents. Cette logique déclarative reste lisible et facile à maintenir, notamment pour les équipes réduites.
Performances : CSS natif vs JavaScript
C'est l'argument décisif. Les animations JavaScript pilotées par scroll s'exécutent sur le thread principal. Chaque événement de défilement déclenche un calcul, ce qui peut provoquer du jank — ces saccades visibles quand le thread sature.
Les animations CSS scroll-driven, à l'inverse, tournent sur le thread compositeur du navigateur. Le défilement reste fluide même pendant que le thread principal traite d'autres tâches. Le bénéfice est direct sur les Core Web Vitals.
Critère | CSS scroll-driven natif | JavaScript (GSAP, scroll listeners) |
|---|---|---|
Thread d'exécution | Compositeur (off-main-thread) | Thread principal |
Poids ajouté | 0 Ko | 30 à 70 Ko (librairie) |
Risque de jank | Très faible | Moyen à élevé |
Impact sur l'INP | Quasi nul | Mesurable sous charge |
Maintenance | Déclarative, en CSS | Impérative, en JS |
Compatibilité 2026 | Globale (avec fallback) | Globale |
Supprimer une librairie d'animation, c'est souvent économiser entre 30 et 70 Ko de JavaScript. Sur une connexion mobile, ces kilo-octets retardent l'interactivité. Or l'INP, métrique clé depuis 2024, sanctionne précisément cette latence.
Si la rapidité de votre site vous préoccupe, sachez que ces optimisations s'inscrivent dans une démarche plus large autour des nouveaux seuils Core Web Vitals 2026. Alléger le JavaScript reste le levier le plus rentable.
Compatibilité et stratégie de fallback
En 2026, le support des animations CSS scroll-driven est généralisé sur les navigateurs evergreen. Néanmoins, une stratégie de dégradation gracieuse reste indispensable pour les versions plus anciennes.
La bonne nouvelle : la dégradation est naturelle. Si animation-timeline n'est pas reconnu, l'animation ne se joue tout simplement pas. L'élément reste visible et lisible. Aucun contenu n'est perdu.
Faut-il prévoir un fallback explicite ?
Oui, mais simplement. La règle @supports permet de cibler les navigateurs compatibles et d'éviter tout état intermédiaire indésirable. C'est la méthode que nous recommandons systématiquement.
1.card { opacity: 1; } /* état par défaut, toujours visible */23@supports (animation-timeline: view()) {4 .card {5 opacity: 0;6 animation: fade-in linear both;7 animation-timeline: view();8 }9}
Ainsi, sur un navigateur ancien, la carte reste visible. Sur un navigateur moderne, elle s'anime. Personne n'est pénalisé. De plus, pensez à prefers-reduced-motion : respecter ce réglage d'accessibilité est non négociable.
1@media (prefers-reduced-motion: reduce) {2 .card { animation: none; opacity: 1; }3}
Cette approche progressive s'aligne sur d'autres standards CSS récents que nous déployons, comme les Container Queries pour un responsive moderne ou la View Transitions API pour des transitions fluides. Le web natif rattrape enfin les frameworks.
Migrer vers ces techniques demande méthode et expérience. Notre équipe à Ussel peut auditer votre design system et planifier la bascule sans régression — demandez un devis personnalisé.
Questions fréquentes sur les animations CSS scroll-driven
Les animations CSS scroll-driven fonctionnent-elles sur tous les navigateurs ?
Oui, en 2026 le support est généralisé sur Chrome, Edge, Firefox et Safari récents. Pour les navigateurs anciens, une dégradation gracieuse via @supports garantit que le contenu reste visible. L'effet ne se joue pas, mais rien n'est cassé. C'est l'approche la plus sûre en production.
Faut-il abandonner GSAP et les autres librairies ?
Pas systématiquement. Pour des effets de scroll simples — barres de progression, révélations, parallaxes — le CSS natif suffit et allège votre site. En revanche, pour des animations complexes orchestrées avec timelines imbriquées ou interactions avancées, une librairie comme GSAP garde tout son intérêt. Choisissez selon le besoin réel.
Le scroll-driven CSS améliore-t-il vraiment les performances ?
Oui, et nettement. Ces animations s'exécutent sur le thread compositeur, hors du thread principal. Le défilement reste fluide même sous charge, ce qui réduit le risque de saccades. Supprimer une librairie économise aussi 30 à 70 Ko de JavaScript, avec un effet direct sur l'INP et le temps d'interactivité.
Comment respecter l'accessibilité avec ces animations ?
Utilisez toujours la requête média prefers-reduced-motion. Certains utilisateurs désactivent les animations pour des raisons de confort ou de santé. En détectant ce réglage, vous coupez les effets de mouvement tout en gardant le contenu accessible. C'est une bonne pratique, et souvent une obligation légale d'accessibilité.
Pour aller plus loin
- MDN — CSS scroll-driven animations : la référence officielle, avec exemples et propriétés détaillées.
- scroll-driven-animations.style : une galerie de démos interactives signée par l'équipe Chrome.
- Can I use — animation-timeline : pour vérifier en temps réel la compatibilité navigateur.
Articles liés
Better Auth en 2026 : l'authentification TypeScript self-hosted
Better Auth en 2026 : sessions, 2FA et passkeys en TypeScript self-hosted. Comparez avec Auth.js et Lucia, intégration framework et bonnes pratiques de sécurité.
Lire →TanStack Start en 2026 : le full-stack React type-safe
Découvrez TanStack Start en 2026 : le meta-framework React full-stack et type-safe. Server functions, streaming, comparaison avec Next.js et quand l'adopter.
Lire →Turso et libSQL : SQLite à l'edge pour vos apps en 2026
Turso et libSQL en 2026 : découvrez le SQLite distribué à l'edge, sa réplication multi-régions, sa latence réduite et quand le préférer à Postgres.
Lire →


