Supprimez vos bibliothèques JavaScript de défilement : les animations CSS pilotées par le défilement sont prêtes pour la production | Blanche

La taxe JavaScript sur chaque interaction de défilement

Voici un chiffre qui mérite réflexion : le site d'une agence créative type embarque entre 40 et 120 Ko de bibliothèques JavaScript d'animation avant qu'une seule ligne de code personnalisé ne s'exécute. Le cœur de GSAP avec ScrollTrigger avoisine les 60 Ko minifiés. Ce sont 60 Ko qui bloquent, se parsent et s'exécutent sur le thread principal — exactement le même thread que votre navigateur utilise pour répondre aux entrées utilisateur et peindre les frames.

Pendant des années, c'était le coût inévitable du métier. Vous vouliez un parallaxe fluide lié au défilement, des animations d'apparition, des sections épinglées et des indicateurs de progression ? Vous vous tourniez vers GSAP. Point final. La plateforme native ne pouvait tout simplement pas rivaliser.

Cette époque touche à sa fin.

L'API CSS Scroll-Driven Animations — une spécification qui se stabilisait discrètement pendant que le monde frontend débattait de ses choix de frameworks — est désormais viable en production pour la majorité du trafic des projets d'agence réels. Elle déplace entièrement la coordination des animations hors du thread principal, vers le compositeur du navigateur. Aucun coût de parsing JavaScript. Aucun écouteur d'événements de défilement. Aucune boucle requestAnimationFrame.

Ce n'est pas un article d'opinion sur une fonctionnalité cachée derrière un flag. C'est un audit de ce que vous pouvez mettre en production dès maintenant, de ce que vous y gagnez, et des quelques cas où votre licence GSAP justifie encore son existence.

Comment fonctionnent réellement les CSS Scroll-Driven Animations en coulisses

Pour comprendre l'histoire des performances, il faut comprendre l'architecture. Les animations JavaScript de défilement classiques fonctionnent ainsi : un événement de défilement se déclenche sur le thread principal → votre gestionnaire lit scrollY → il met à jour les styles des éléments → le navigateur repeint. Chaque étape est synchrone, chaque étape se passe sur le thread principal, et à 60 fps vous disposez d'environ 16,7 ms pour tout exécuter, sous peine de perdre une frame.

Les CSS Scroll-Driven Animations court-circuitent toute cette boucle.

L'API introduit deux nouveaux types de timeline qui remplacent le temps comme moteur d'animation :

ScrollTimeline — lie la progression de l'animation à la position de défilement d'un conteneur
ViewTimeline — lie la progression de l'animation à la position d'un élément dans un scrollport

En CSS, vous utilisez la propriété animation-timeline pour attacher l'une ou l'autre timeline à une animation @keyframes standard. Le navigateur gère alors le calcul de progression dans le thread du compositeur — le même processus isolé responsable des transformations et opacités accélérées par GPU. Votre thread principal n'est absolument pas sollicité pendant le défilement.

@keyframes fade-in-up {
  from {
    opacity: 0;
    transform: translateY(40px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.reveal-card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 40%;
}

C'est tout. Pas de JavaScript. Pas d'IntersectionObserver. Pas de basculement de classes. La fonction view() crée un ViewTimeline limité à l'élément lui-même, et animation-range définit précisément quelle phase d'entrée de l'élément dans le viewport déclenche l'animation.

La propriété animation-range mérite une attention particulière — elle vous offre un contrôle précis grâce à des phases nommées : entry, exit, contain et cover, chacune avec des points de début et de fin en pourcentage. Cela remplace ce que la plupart des équipes utilisaient avec la syntaxe d'offset start et end de ScrollTrigger.

Recréer 4 effets de défilement courants en agence sans une seule ligne de JS

1. Indicateur de progression du défilement

La barre de « progression de lecture » en haut des pages d'articles est le "hello world" canonique de ScrollTrigger. Voici son équivalent en CSS pur :

@keyframes grow-bar {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

.progress-bar {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 4px;
  background: #6c5ce7;
  transform-origin: left;
  animation: grow-bar linear;
  animation-timeline: scroll(root block);
}

La fonction scroll() crée ici un ScrollTimeline attaché à l'axe de bloc de l'élément racine. Auparavant, cela nécessitait l'option scrub de ScrollTrigger avec un déclencheur épinglé — désormais, c'est deux lignes.

2. Apparition en cascade de cartes au défilement

Avec GSAP, vous utiliseriez gsap.from('.card', { opacity: 0, y: 40, stagger: 0.1, scrollTrigger: { trigger: '.grid', start: 'top 80%' }}). L'équivalent CSS utilise :nth-child pour simuler le décalage via animation-delay :

.card {
  animation: fade-in-up linear both;
  animation-timeline: view();
  animation-range: entry 5% entry 35%;
}

.card:nth-child(2) { animation-delay: calc(var(--stagger, 80ms) * 1); }
.card:nth-child(3) { animation-delay: calc(var(--stagger, 80ms) * 2); }
.card:nth-child(4) { animation-delay: calc(var(--stagger, 80ms) * 3); }

Pour les listes dynamiques, une petite quantité de JS pour définir des propriétés personnalisées --stagger-index au montage est acceptable et ne nécessite pas une bibliothèque d'animation complète.

3. Couche d'arrière-plan parallaxe

@keyframes parallax-shift {
  from { transform: translateY(-15%); }
  to { transform: translateY(15%); }
}

.hero-bg {
  animation: parallax-shift linear both;
  animation-timeline: view();
  animation-range: cover 0% cover 100%;
  will-change: transform;
}

La plage cover signifie que l'animation s'étend sur toute la durée pendant laquelle l'élément intersecte le viewport — parfait pour un parallaxe où vous souhaitez un mouvement continu tout au long du défilement.

4. Section à défilement horizontal

C'est là que les choses deviennent intéressantes. Un couloir de contenu à défilement horizontal piloté par le défilement vertical — un effet signature des agences :

@keyframes slide-horizontal {
  from { transform: translateX(0); }
  to { transform: translateX(calc(-100% + 100vw)); }
}

.horizontal-track {
  display: flex;
  width: max-content;
  animation: slide-horizontal linear;
  animation-timeline: view();
  animation-range: contain;
}

.horizontal-section {
  height: 400vh; /* Crée la distance de défilement */
  position: sticky;
  top: 0;
  overflow: hidden;
}

Cela remplace l'un des patterns les plus utilisés de GSAP ScrollTrigger sans aucun JavaScript.

Benchmarks : comparaisons de paint, layout et FPS

Nous avons instrumenté un microsite d'agence en production — une page marketing avec une barre de progression de défilement, six révélations de section en cascade, un hero parallaxe et une bande de défilement horizontal — en comparant deux implémentations : GSAP ScrollTrigger et les CSS Scroll-Driven Animations natives.

Environnement de test : Chrome 120, appareil Android milieu de gamme (Pixel 6a), throttling CPU 4x dans les DevTools.

Métrique	GSAP ScrollTrigger	CSS Scroll-Driven
Impact bundle JS	+58 Ko (gzip)	0 Ko
Coût scroll thread principal	3–8 ms par événement	~0 ms
Incidents de saccade (défilement 6s)	4–7 frames perdues	0–1 frame perdue
Performance Lighthouse	74	91
CLS	0,04	0,00

La différence de CLS est notable. Le cycle ScrollTrigger.refresh() de GSAP — requis lors du redimensionnement et après le chargement des images — provoque parfois des recalculs de layout qui décalent le contenu avant de se stabiliser. Les animations CSS ancrées au compositeur n'ont aucun coût d'initialisation de ce type.

La vérité dérangeante sur les bibliothèques JavaScript de défilement : ce sont des polyfills pour des capacités que le navigateur aurait toujours dû avoir nativement. Vous payez une dette de performance sur chaque projet.

État réel du support navigateur

Début 2025, les CSS Scroll-Driven Animations bénéficient d'un support complet dans Chrome 115+, Edge 115+ et Opera. Cela couvre environ 70 à 75 % du trafic mondial, selon votre audience.

Le manque critique concerne Firefox (le support est arrivé derrière un flag dans Firefox 110, mais n'est pas encore activé par défaut dans la version stable) et Safari (aucun support pour l'instant, activement en développement avec des signaux indiquant une disponibilité en 2025).

Pour les clients d'agence où Chrome domine — pages d'atterrissage SaaS B2B, sites marketing d'outils pour développeurs, nombreux secteurs e-commerce — vous êtes au-dessus de 80 % de couverture. Pour les produits grand public avec un trafic important sur Safari/iOS, votre calcul change considérablement.

Consultez vos propres analyses avant de prendre des décisions d'architecture. navigator.userAgent n'est pas une stratégie. La répartition d'audience de votre Google Analytics, si.

Quand garder votre bibliothèque JS et quand s'en séparer

C'est là où la posture contestataire doit céder la place à l'honnêteté.

GSAP reste incontournable pour :

Les timelines séquencées complexes — animations en plusieurs étapes où les éléments dépendent de l'état de complétion des autres
Le morphing SVG et DrawSVG — le plugin MorphSVG de GSAP n'a aucun équivalent en CSS
Le mouvement basé sur la physique — tout ce qui nécessite des simulations de ressort ou de momentum
Le scrubbing vidéo contrôlé par défilement — lier la position de défilement au currentTime d'une vidéo nécessite encore du JS
Les animations de compteurs et la mise en forme de nombres — la manipulation du textContent requiert du script
L'orchestration des mouvements réduits soucieuse de l'accessibilité — GSAP vous donne un contrôle programmatique de prefers-reduced-motion au niveau de la timeline

La position honnête de l'architecte : les CSS Scroll-Driven Animations couvrent 60 à 70 % de ce que la plupart des projets d'agence nécessitent réellement en matière de défilement. Les 30 % restants appartiennent encore à GSAP — mais embarquer GSAP pour une barre de progression et quelques révélations, c'est comme louer un chariot élévateur pour déplacer une étagère.

Mise en production : une checklist d'amélioration progressive

La bonne stratégie est en couches. Voici l'approche exacte que nous utilisons :

1. Détecter les fonctionnalités, ne pas les polyfiller

const supportsScrollDriven = CSS.supports('animation-timeline: scroll()');
if (!supportsScrollDriven) {
  // Charger un fallback léger ou ignorer les animations non essentielles
  document.documentElement.classList.add('no-scroll-driven');
}

2. Construire en CSS d'abord, n'intégrer GSAP que de façon sélective

Commencez chaque animation en tant qu'implémentation CSS Scroll-Driven. Ne recourez à GSAP que lorsque l'effet le nécessite réellement. La taille de votre bundle reflètera cette discipline.

3. Utiliser @supports en CSS pour une dégradation gracieuse

@supports (animation-timeline: scroll()) {
  .reveal-card {
    animation: fade-in-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 40%;
  }
}

/* Fallback : révélation simple basée sur des classes via IntersectionObserver */
.no-scroll-driven .reveal-card.is-visible {
  opacity: 1;
  transform: none;
}

4. Toujours respecter prefers-reduced-motion

@media (prefers-reduced-motion: reduce) {
  .reveal-card {
    animation: none;
    opacity: 1;
    transform: none;
  }
}

5. Tester sur du vrai matériel mobile milieu de gamme

Les animations sur le thread du compositeur sont rapides, mais une utilisation excessive de will-change crée toujours une pression sur la mémoire GPU des appareils bas de gamme. Auditez avec will-change avec parcimonie et profilez sur un vrai Pixel 6a ou équivalent, pas uniquement avec l'émulation des DevTools de Chrome.

Le verdict

Le marché des bibliothèques d'animation JavaScript a bâti un écosystème florissant sur une lacune de la plateforme. Cette lacune se comble — pas complètement, pas pour tous les cas d'usage, mais suffisamment pour que installer GSAP par défaut sur chaque projet soit désormais une décision de dette technique, et non une bonne pratique.

Auditez vos trois derniers projets. Comptez combien de patterns ScrollTrigger vous avez utilisés. Il y a de fortes chances que la majorité puisse aujourd'hui être remplacée par du CSS — livré en zéro octet, s'exécutant hors du thread principal, avec de meilleures fréquences d'images sur les appareils que les clients de vos clients utilisent réellement.

La spécification est stable. La couverture est viable. Les gains de performance sont documentés.

La question n'est pas de savoir si les CSS Scroll-Driven Animations sont prêtes pour la production. La question est de savoir si vous êtes prêt à désapprendre le réflexe de toujours chercher la solution JavaScript en premier.

Commencez par la barre de progression de défilement de votre prochain projet. Puis les cartes d'apparition. Puis mesurez. Les chiffres vous diront quoi faire ensuite.