Matando la Dependencia de JS: Cómo las Animaciones Nativas Basadas en Scroll Están Reescribiendo las Reglas del Rendimiento Frontend | Blanche

Los efectos de scroll tienen un sucio secreto. Cada capa de parallax, cada barra de progreso de scroll, cada revelación sticky que hayas publicado probablemente vino empaquetada con una carga de JavaScript que está silenciosamente destruyendo el hilo principal de tus usuarios.

ScrollTrigger de GSAP es brillante — nadie lo discute. Pero sigue siendo JavaScript ejecutándose en el hilo principal, compitiendo por ciclos de CPU con la lógica de tu aplicación, tus etiquetas de analíticas y las otras diecisiete bibliotecas que tu product manager insistió en incluir. El hilo compositor del navegador — la parte diseñada específicamente para un renderizado visual suave como la seda — ha estado mayormente inactivo mientras JS hace el trabajo pesado para el que nunca fue diseñado.

Eso está cambiando. La API de Animaciones CSS Basadas en Scroll acaba de trasladar toda la conversación a donde siempre debió haber estado: el pipeline de renderizado nativo del navegador.

Qué Hace Realmente la API de Animaciones Basadas en Scroll

En su núcleo, la API de Animaciones Basadas en Scroll le otorga a CSS (y a una delgada capa de JavaScript, si la necesitas) la capacidad de vincular líneas de tiempo de animación directamente a la posición del scroll — sin ningún listener de eventos de scroll, sin bucles requestAnimationFrame, sin layout thrashing.

La API introduce dos nuevos tipos de líneas de tiempo:

ScrollTimeline — vincula el progreso de una animación a la posición de scroll de un contenedor
ViewTimeline — vincula el progreso de una animación a la posición de un elemento dentro de un viewport de scroll (cuando entra, atraviesa y sale del viewport)

En CSS, esto parece engañosamente simple:

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

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

Eso es todo. Sin IntersectionObserver. Sin listener de eventos de scroll. Sin JavaScript en absoluto.

La diferencia arquitectónica crítica: las animaciones basadas en scroll se ejecutan fuera del hilo principal en los navegadores compatibles. El compositor de Chrome asume el trabajo por completo, lo que significa que incluso si tu hilo principal está bloqueado por una tarea larga, tus animaciones de scroll siguen ejecutándose a 60fps (o 120fps en pantallas de alta frecuencia de actualización). Esa es una brecha de capacidad que ninguna solución JS basada en polyfills puede cerrar — porque JavaScript en sí mismo es el cuello de botella.

Soporte Actual de Navegadores

A mediados de 2025, Chrome y Edge tienen soporte completo (Chrome 115+). Firefox lo implementó detrás de una bandera y está trabajando activamente hacia una versión estable. Safari sigue siendo el rezagado — sin soporte aún, aunque el equipo de WebKit ha reconocido la especificación.

Esto significa que necesitas una estrategia de respaldo hoy, pero la trayectoria es clara. La consulta @supports y un shim de JS ligero (el polyfill scroll-driven-animations en npm) pueden cubrir la brecha sin degradar tu UX.

Benchmarks de Rendimiento: CSS vs. JS Frente a Frente

Seamos concretos. Cuando Bramus Van Damme (Google Chrome DevRel) demostró la API en el Chrome Dev Summit, los datos de fotogramas contaron una historia contundente. Pero no necesitas una conferencia — puedes reproducirlo tú mismo en DevTools.

El Escenario de Prueba

Consideremos una página con 20 tarjetas animadas por scroll, cada una usando un efecto de desplazamiento parallax:

Implementación con GSAP ScrollTrigger:

Adjunta un listener de scroll en window
En cada evento de scroll, itera sobre 20 elementos
Llama a gsap.set() por elemento, disparando recálculos de estilo
Perfil de jank típico: 4–8ms de scripting por evento de scroll, fotogramas caídos ocasionales en hardware Android de gama media

Implementación con Animaciones CSS Basadas en Scroll:

Cero listeners de eventos de scroll
Cero ejecución de JavaScript durante el scroll
Ejecución en el hilo compositor: tiempo de scripting constante de 0ms durante el scroll
Presupuesto de tiempo de fotograma: efectivamente igual al de una página estática

La diferencia no es marginal. En un dispositivo de clase Moto G4 (el benchmark estándar de throttling), las animaciones CSS basadas en scroll pueden mantener 60fps en interacciones donde GSAP ScrollTrigger cae al rango de 40–45fps bajo carga del mundo real.

Esto no es una crítica a GSAP — es un problema de física. El manejo de scroll con JavaScript tiene un costo mínimo irreducible debido a cómo funciona el event loop. El CSS ejecutándose en el compositor no tiene ese límite.

Impacto en Lighthouse / INP: Con el cambio a Interaction to Next Paint como Core Web Vital, los manejadores de scroll en el hilo principal son una preocupación real de posicionamiento. Las animaciones CSS de scroll simplemente no se registran en tu presupuesto de INP.

5 Patrones de Implementación del Mundo Real para Usar Hoy

1. Barra de Progreso de Scroll

El clásico. Una barra delgada en la parte superior de la página que se llena mientras haces scroll.

#progress-bar {
  position: fixed;
  top: 0; left: 0;
  width: 100%; height: 4px;
  background: linear-gradient(to right, #6366f1, #8b5cf6);
  transform-origin: left;
  animation: progress-grow linear;
  animation-timeline: scroll(root block);
}

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

Antes esto requería un listener de scroll y un cálculo manual del ancho. Ahora son ocho líneas de CSS.

2. Fondos con Parallax

Usa view() con un animation-range negativo para crear el efecto de desplazamiento parallax mientras una sección entra al viewport:

.hero-bg {
  animation: parallax-shift linear;
  animation-timeline: view();
  animation-range: cover;
}

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

3. Revelaciones Sticky Vinculadas al Scroll

Anima contenido con position: sticky según qué tan lejos ha hecho scroll el usuario dentro de una sección:

.sticky-label {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 10% entry 60%;
}

4. Galería de Scroll Horizontal

Uno de los patrones más difíciles en JS se vuelve declarativo:

.gallery-track {
  animation: slide-horizontal linear;
  animation-timeline: scroll(nearest inline);
}

@keyframes slide-horizontal {
  from { transform: translateX(0); }
  to   { transform: translateX(-66.6%); }
}

5. Entrada Escalonada de Tarjetas

Combina ViewTimeline con propiedades personalizadas de CSS y animation-delay para crear efectos de entrada en cascada sin una sola línea de JavaScript:

.card:nth-child(1) { --delay: 0ms; }
.card:nth-child(2) { --delay: 80ms; }
.card:nth-child(3) { --delay: 160ms; }

.card {
  animation: card-enter linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 50%;
  animation-delay: var(--delay);
}

Accesibilidad, Soporte de Navegadores y Casos Límite a Conocer

prefers-reduced-motion Es Innegociable

Las animaciones basadas en scroll son movimiento por definición. Para usuarios con trastornos vestibulares o sensibilidades al movimiento, el desplazamiento no solicitado vinculado al scroll puede desencadenar molestias físicas reales.

Envuelve todas tus declaraciones de animación de scroll:

@media (prefers-reduced-motion: no-preference) {
  .card {
    animation: reveal linear;
    animation-timeline: view();
  }
}

No solo reduzcas el movimiento — elimínalo por completo para los usuarios que han optado por no tenerlo. Una animación más sutil sigue siendo una animación que no pidieron.

La Brecha del Polyfill

Para Safari y Firefox estable, usa el polyfill @scroll-driven-animations. Recurre a un enfoque de ResizeObserver + listener de scroll, que obviamente no te brinda los beneficios fuera del hilo principal — pero proporciona paridad visual. Trátalo como una capa de degradación elegante, no como una solución permanente.

Casos Límite que Vale la Pena Probar

Scrollers anidados: scroll() y view() toman por defecto el scroller ancestro más cercano. Sé explícito con scroll(root) vs. scroll(nearest) cuando tu layout es complejo.
animation-fill-mode: Usa both para asegurarte de que los elementos comiencen en su estado from antes de que se alcance el rango de animación.
Contenido dinámico: Si la altura de tu contenedor de scroll cambia después de la carga (imágenes con carga diferida, contenido de CMS), la línea de tiempo de animación se recalcula automáticamente — pero verifica que esto no cause FOUC en tu layout específico.

Cuándo las Bibliotecas de Scroll en JavaScript Siguen Siendo la Herramienta Correcta

Esto no es un manifiesto contra GSAP. Todavía hay escenarios claros donde recurrir a ScrollTrigger o Lenis es la decisión correcta:

Secuencias orquestadas complejas donde múltiples elementos se animan en respuesta a un único disparador de scroll con tiempos interdependientes
Scroll-jacking / scroll con inercia estilo locomotive — la API no controla el comportamiento del scroll, solo el estado de la animación
Paridad entre navegadores hoy sin una estrategia de polyfill, especialmente en audiencias con mucho uso de Safari (te miro a ti, finanzas de consumo y e-commerce de lujo)
Secciones de scroll fijadas con máquinas de estado complejas que van más allá de lo que los keyframes de CSS pueden expresar limpiamente
Scrubbing de línea de tiempo vinculado a entradas que no son scroll (posición del ratón, giroscopio, etc.)

El marco honesto: si tu animación puede expresarse como «el estado visual de este elemento es una función pura de la posición del scroll», CSS gana. Si tu animación requiere condicionales, secuenciación de eventos o entradas que no sean de scroll, JavaScript sigue siendo tu herramienta.

Conclusión: ¿Es Esto el Principio del Fin para ScrollTrigger?

Aún no — pero el techo se está cerrando.

La API de Animaciones CSS Basadas en Scroll no reemplaza a GSAP ScrollTrigger de la forma en que React reemplazó a jQuery. Reemplaza un patrón de uso específico — retroalimentación visual pasiva y vinculada a la posición — con una solución nativa vastamente más eficiente. Y ese patrón cubre probablemente el 60–70% de para qué se usan realmente las bibliotecas de scroll en producción.

Los desarrolladores que ganarán en los próximos dos años son los que recurren primero a lo nativo, incorporan JavaScript solo donde justifica su peso en la carga, y construyen arquitecturas de animación que no toman el rendimiento como rehén de decisiones de bibliotecas tomadas en 2019.

Publica una barra de progreso de scroll en CSS hoy. Construye tu próxima sección de parallax sin un solo addEventListener. Ejecuta el trace de DevTools y observa cómo tu hilo principal se queda en silencio durante el scroll por primera vez.

Luego pregúntate si esa dependencia de GSAP todavía merece un lugar en tu bundle.

El navegador es más capaz de lo que asume tu configuración de build. Es hora de dejarlo hacer su trabajo.