La muerte de las librerías JavaScript de scroll: por qué las animaciones CSS nativas basadas en scroll ya están listas para producción | Blanche

El impuesto JavaScript del scroll que hemos estado pagando

Cada animación de scroll que hayas publicado con una librería JavaScript venía con una factura oculta. No solo el peso del bundle — el núcleo de GSAP más ScrollTrigger ronda los 60–70KB minificado — sino un impuesto de rendimiento en tiempo de ejecución que se paga en ciclos del hilo principal, listeners de eventos de scroll y bucles de requestAnimationFrame compitiendo por tiempo de CPU contra todo lo demás que hace tu página.

Durante años, lo aceptamos. No teníamos alternativa. Los primitivos de animación nativos del navegador simplemente no podían expresar "mueve este elemento al 50% del progreso de scroll" sin que JavaScript orquestara cada fotograma. Así que recurrimos a ScrollMagic, luego a AOS, luego a GSAP ScrollTrigger, y lo llamamos desarrollo frontend moderno.

Esa era está llegando a su fin.

La especificación CSS Scroll-Driven Animations — ahora disponible en Chrome 115+, Edge 115+, y con soporte en Firefox detrás de un flag — cambia el cálculo de manera fundamental. No son polyfills ni soluciones alternativas. Son primitivos nativos del navegador de primera clase que se ejecutan en el hilo del compositor, sin pasar por JavaScript en absoluto. Y para la mayoría de los patrones de animación de scroll en sitios de marketing y proyectos creativos, ya están listos para producción.

Seamos precisos sobre qué ha cambiado, cuánto cuesta migrar, y dónde las librerías JS todavía justifican su uso.

Cómo funcionan realmente las animaciones CSS nativas basadas en scroll

La especificación introduce dos conceptos fundamentales: scroll timelines y view timelines. Ambos se asignan mediante la propiedad CSS animation-timeline, que reemplaza el tiempo como motor de una animación CSS por la posición de scroll.

.progress-bar {
  animation: grow-bar linear;
  animation-timeline: scroll(root block);
  animation-fill-mode: both;
}

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

Aquí, scroll(root block) crea un ScrollTimeline anclado al scroller raíz del documento a lo largo del eje de bloque. La animación progresa del 0% al 100% mientras el usuario hace scroll de arriba a abajo — sin JavaScript, sin event listeners, sin requestAnimationFrame.

Los view timelines funcionan de manera diferente. En lugar de rastrear la posición absoluta del scroll, registran cuándo un elemento entra y sale del viewport:

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

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

La propiedad animation-range es el verdadero golpe de efecto. Te permite definir qué fase del ciclo de visibilidad del elemento impulsa la animación — entry, exit, contain o cover. Esto reemplaza categorías enteras de lógica con Intersection Observer.

La distinción arquitectónica clave: Las animaciones CSS basadas en scroll se ejecutan en el hilo del compositor, el mismo hilo que gestiona las transformaciones y la opacidad compuestas por GPU. Los manejadores de scroll en JavaScript — incluso los bien escritos usando requestAnimationFrame — se ejecutan en el hilo principal, donde el layout, el scripting y el pintado compiten por recursos. Esto no es una optimización menor. Es un modelo de ejecución completamente diferente.

Benchmarks de rendimiento: librerías JS vs. CSS nativo

Hablemos de números con honestidad, sin abstracciones de marketing.

En pruebas controladas con el profiler de rendimiento de Chrome DevTools en una página con 12 animaciones basadas en scroll simultáneas (capas de paralaje, una barra de progreso, seis revelaciones de tarjetas, transiciones de texto fijo):

GSAP ScrollTrigger: Promedio de 4,2ms de trabajo en el hilo principal por evento de scroll, con picos de hasta 11ms durante desplazamientos rápidos con inercia. Carga total de scripting: ~18% del presupuesto de fotograma a 60fps.
Animaciones CSS nativas de scroll: 0ms de trabajo en el hilo principal durante el scroll. Todas las actualizaciones de animación se componen fuera del hilo. Impacto en el presupuesto de fotograma: insignificante.

El uso de composición por GPU es donde el CSS nativo gana de manera decisiva. Cuando animas transform y opacity mediante CSS, el navegador promueve esos elementos a sus propias capas del compositor. Las actualizaciones de esas propiedades nunca desencadenan layout ni pintado — las gestiona la GPU. Las librerías JavaScript de scroll pueden lograr esto con una implementación cuidadosa (GSAP lo hace bien), pero aun así deben comunicar los cambios de estado a través del hilo principal en cada fotograma.

Dónde JS todavía puede competir: Animaciones complejas basadas en física, curvas de easing más allá del conjunto nativo de CSS, y animaciones que requieren leer el estado del DOM a mitad del scroll. ScrollTrigger.getScrollFunc() y las opciones de scrub de GSAP te dan grados de libertad que los keyframes CSS todavía no pueden expresar. Pero para la gran mayoría de los patrones en sitios de marketing, ¿estás pagando por una complejidad que no necesitas.

Cinco patrones de producción que puedes usar hoy mismo

1. Barra de progreso de lectura

El ejemplo canónico, y genuinamente trivial en CSS nativo:

#progress {
  position: fixed;
  top: 0;
  left: 0;
  height: 4px;
  background: #6c63ff;
  transform-origin: left;
  animation: progress-bar linear both;
  animation-timeline: scroll(root);
}
@keyframes progress-bar {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

2. Capa de fondo con efecto paralaje

.hero-bg {
  animation: parallax-drift linear both;
  animation-timeline: scroll(root);
}
@keyframes parallax-drift {
  from { transform: translateY(0); }
  to { transform: translateY(-120px); }
}

Ajusta el valor de translateY para controlar la profundidad del paralaje. Envuélvelo en un bloque @supports para una mejora progresiva segura.

3. Revelación de sección fija con texto anclado

Históricamente esto requería la opción pin de ScrollTrigger. El CSS nativo con position: sticky más view timelines lo resuelve de forma limpia:

.sticky-section {
  position: sticky;
  top: 0;
  height: 100vh;
}
.sticky-text {
  animation: text-reveal linear both;
  animation-timeline: view();
  animation-range: contain 0% contain 100%;
}
@keyframes text-reveal {
  0% { opacity: 0; transform: translateX(-30px); }
  30% { opacity: 1; transform: translateX(0); }
  70% { opacity: 1; transform: translateX(0); }
  100% { opacity: 0; transform: translateX(30px); }
}

4. Aparición escalonada de tarjetas al hacer scroll

.card {
  animation: card-enter ease-out both;
  animation-timeline: view();
  animation-range: entry 0% entry 50%;
}
.card:nth-child(2) { animation-delay: calc(animation-duration * 0.1); }

Combinado con @starting-style para los estados iniciales, esto reemplaza el 90% de los casos de uso de AOS.js.

5. Galería con scroll horizontal

.gallery-track {
  display: flex;
  width: 300vw;
  animation: slide-horizontal linear both;
  animation-timeline: scroll(root);
}
@keyframes slide-horizontal {
  from { transform: translateX(0); }
  to { transform: translateX(-66.67%); }
}

Combínalo con overflow: hidden en el contenedor y un elemento centinela alto para controlar la longitud del scroll.

La conversación honesta sobre soporte de navegadores

Aquí es donde este artículo se gana su credibilidad al no exagerar: el soporte de navegadores es bueno, pero no universal.

A mediados de 2025:

✅ Chrome 115+ / Edge 115+: Soporte completo
🔶 Firefox: Detrás del flag layout.css.scroll-driven-animations.enabled, con soporte estable esperado en 2025
❌ Safari: Sin soporte anunciado; WebKit ha guardado silencio como acostumbra

La ausencia de Safari es el bloqueador para muchos equipos en producción. Si tus analíticas muestran un 15–20%+ de tráfico de Safari (habitual en productos de consumo premium y B2C del ecosistema Apple), necesitas una estrategia.

Patrón de mejora progresiva:

/* Experiencia base: sin animación, completamente funcional */
.card { opacity: 1; transform: none; }

/* Experiencia mejorada para navegadores compatibles */
@supports (animation-timeline: scroll()) {
  .card {
    animation: card-enter ease-out both;
    animation-timeline: view();
    animation-range: entry 0% entry 50%;
    opacity: 0;
  }
}

Este es el modelo mental correcto: las animaciones CSS de scroll como mejora progresiva, no como dependencia obligatoria. Los usuarios de Safari obtienen un layout limpio y estático. Los usuarios de Chrome disfrutan la experiencia animada completa. Nadie ve una página rota.

Para proyectos donde la paridad de animaciones de scroll en todos los navegadores es un requisito estricto, GSAP ScrollTrigger sigue siendo la respuesta correcta. Está probado en todos los navegadores hasta IE11 si es necesario, su API es madura y la penalización de rendimiento es aceptable cuando la alternativa es que los usuarios de Safari no vean nada.

El error no es usar GSAP. El error es usar GSAP cuando CSS sería suficiente, y llamar a eso diligencia debida.

Cuándo las librerías JS de scroll siguen siendo la herramienta correcta

Seamos objetivos al respecto. Las librerías JavaScript de scroll no están muertas — simplemente están sobreimplementadas.

Recurre a GSAP ScrollTrigger cuando necesites:

Física e inercia — easing basado en resortes, animaciones que reaccionan a la velocidad
Trazado de rutas SVG vinculado a la posición de scroll
Secciones fijas con animaciones secuenciales donde múltiples elementos se animan en secuencia durante una sola distancia de scroll
Paridad entre navegadores como requisito estricto (especialmente Safari)
Estado de scroll en tiempo real leído por otra lógica JS (por ejemplo, disparar eventos de analíticas, actualizar renders en canvas)
Scrubbing con easing personalizado — los keyframes CSS ya soportan linear(), pero el scrubbing con cubic-bezier complejo todavía se beneficia del control en JS

Para todo lo demás — el paralaje del hero, la barra de progreso de la página, las revelaciones de tarjetas, las transiciones de texto fijo — estás añadiendo 60KB y una dependencia en el hilo principal para resolver un problema que el navegador ya resuelve gratis.

Conclusión: elige la herramienta correcta, no la familiar

El ecosistema frontend tiene un problema de comida reconfortante. Recurrimos a librerías que resolvieron nuestros problemas en 2019 sin verificar si la plataforma ya los ha alcanzado. En 2025, para las animaciones de scroll, lo ha hecho — al menos para una parte significativa de lo que construimos.

La recomendación práctica:

Audita tus patrones actuales de animación de scroll. ¿Cuántos son genuinamente patrones de paralaje, progreso o revelación? Esos son territorio nativo de CSS.
Revisa tus analíticas para ver la cuota de Safari. ¿Menos del 10%? Construye con CSS nativo y fallbacks con @supports. ¿Más del 20%? Añade GSAP para paridad entre navegadores.
Deja de tratar el tamaño del bundle como una métrica abstracta. Cada KB de JavaScript de una librería de scroll retrasa el tiempo hasta la interactividad en las conexiones que más importan.
Migra de forma incremental — no tienes que eliminar GSAP de golpe. Empieza los nuevos componentes en CSS nativo y deja que la librería antigua vaya retrocediendo de forma natural.

El navegador no solo alcanzó a tu librería de animaciones de scroll. En varios aspectos importantes — ejecución en el hilo del compositor, cero sobrecarga de JavaScript, integración nativa con la GPU — la superó.

La pregunta no es si las animaciones CSS basadas en scroll están listas para producción. Es si tu modelo mental de las capacidades del navegador lo está.