Scroll-driven animations: la API nativa del navegador que compite con GSAP ScrollTrigger (y cuándo conviene cada una)

Vas a revisar una landing y el desarrollador te pide “80 KB de librería para la barra de progreso”. Le decís que no, pero no sabés explicar bien por qué. El problema de fondo: para efectos que hoy son una línea de CSS, seguimos instalando bibliotecas que pesan, corren en el main thread y agregan complejidad.

Las scroll-driven animations cambiaron eso. Desde Chrome y Edge 115 (julio 2023) y Safari 18, el navegador puede vincular una animación al scroll con una sola propiedad: animation-timeline: scroll(). Sin JavaScript, sin listeners, sin bundle. En este artículo vas a ver cómo funciona con una demo real de barra de progreso y parallax, la comparación honesta contra GSAP ScrollTrigger y el criterio concreto para elegir en un proyecto real.

Qué es animation-timeline: scroll() y por qué reemplaza 60 KB de JavaScript

Hasta hace poco, “animación vinculada al scroll” significaba un script: escuchar scroll, leer scrollTop, calcular progreso, tocar un elemento en cada frame. Todo eso corre en el main thread, compite con el layout y es justo lo que empeora las métricas de rendimiento de tu sitio.

Con la API nativa, declarás que una animación usa el scroll como timeline, y el navegador se encarga del resto — incluso en el compositor, sin tocar el hilo principal. El ejemplo más clásico, una barra de progreso de lectura, queda en cuatro reglas:

.progress {
  position: sticky;
  top: 0;
  height: 4px;
  transform: scaleX(0);
  transform-origin: left;
  animation: grow linear both;
  animation-timeline: scroll();
}

@keyframes grow {
  to { transform: scaleX(1); }
}

El navegador mapea el progreso del scroll a la animación: 0% al inicio, 100% al final del contenedor scrollable. scroll() usa el ancestro más cercano que haga scroll; scroll(root) fuerza el viewport, y view() permite disparar según cuándo un elemento entra y sale de la pantalla — ideal para reveals y parallax de sección.

La demo: barra de progreso y parallax sin un listener de scroll

Probalo vos mismo: la barra superior crece y la tarjeta destacada se desplaza a otra velocidad usando únicamente las animaciones nativas.

El parallax de la tarjeta es el mismo patrón de la barra, con un keyframe de transform:

.parallax-card {
  animation: float linear both;
  animation-timeline: scroll();
}

@keyframes float {
  to { transform: translateY(-64px); }
}

Dos ajustes importantes para producción. Primero, acotar el rango de la animación con animation-range, así el parallax no se estira hasta el final del scroll: animation-range: 0 60%. Segundo, degradar para navegadores sin soporte envolviendo las reglas en @supports (animation-timeline: scroll()); el contenido queda visible y solo falta el efecto.

Scroll-driven vs GSAP ScrollTrigger: la comparación honesta

GSAP ScrollTrigger (versión 3.13 hoy) sigue siendo una biblioteca excelente, y la comparación no es “nativa buena, librería mala”. Son herramientas con zonas de confort distintas:

• Soporte de navegadores: Chrome y Edge desde la 115, Safari desde la 18, Firefox todavía experimental detrás de una flag. ScrollTrigger funciona en cualquier navegador vivo. Si tu audiencia usa Firefox estable masivamente, la nativa no es opción sin fallback.
• Control fino: ScrollTrigger ofrece scrub con easing, pin (fijar secciones), toggle actions, callbacks y timeline con múltiples elementos coordinados. La API nativa cubre bien el caso “una propiedad animada por progreso de scroll”, y para cronometría compleja hay que ingeniárselas.
• Rendimiento: la nativa corre en el compositor y no pesa nada; ScrollTrigger usa requestAnimationFrame y listeners optimizados — livianos para lo que hacen, pero no gratuitos.
• Mantenimiento: la nativa es CSS que no se actualiza ni se rompe. Una librería es una dependencia más: versiones, breaking changes y bundle (~40 KB mínimos con GSAP completo, menos si importás solo ScrollTrigger y lo tree-shakeás).
• Curva de aprendizaje: la nativa la entendés en una tarde. ScrollTrigger tiene un API enorme que dominás recién después de usarla en varios proyectos.

No hay ganador universal: hay un criterio de decisión.

El criterio para elegir en un proyecto real

En nuestra experiencia — y esto es lo que aplicamos en Gambit Lab en cada landing — la regla práctica es:

• Usá scroll-driven nativa para barra de progreso, reveals, parallax de tarjetas o secciones, animaciones de imágenes y cualquier efecto que sea “una propiedad sincronizada con el scroll”. Es el 80% de los casos de una web de marketing, y el resultado es más liviano y rápido.
• Usá GSAP ScrollTrigger cuando el efecto pida pin (fijar una sección mientras scrolleás), timelines con muchos elementos coordinados, scrub con easing custom o control desde JavaScript (pausar, reproducir, saltar). Ahí el trabajo manual con la API nativa vale menos que la biblioteca.
• En proyectos con audiencia incierta, la degradación con @supports es tu mejor amiga: si el navegador no anima, el contenido sigue siendo perfectamente legible. Un parallax que no se mueve es una decisión de diseño; contenido invisible por culpa de una librería es un bug.

El error más caro no es elegir mal: es instalar una librería para un efecto de tres líneas de CSS y cargar 40 KB que tu web paga en cada visita, sobre todo en móvil, donde el scroll-driven nativo rinde mejor contra el LCP. Si te interesa cómo estas decisiones impactan en las métricas que mide Google, tenés la guía completa sobre Core Web Vitals y rendimiento web.

Mi sugerencia: probá la demo de arriba, abrí las DevTools, y la próxima vez que alguien te pida “instalar la librería para el scroll”, preguntate si estás del lado nativo o del lado ScrollTrigger. La mayoría de las veces la respuesta está en el CSS. Y si querés ver cuándo la animación deja de ser una ventaja y pasa a lastrar la conversión, este análisis sobre landing pages que convierten te da el otro lado de la balanza.