El cementerio de JavaScript: cómo las animaciones de scroll nativas en CSS están volviendo obsoletas tus bibliotecas de animación
La API de animaciones de scroll de CSS acaba de llegar a los navegadores estables — y está desmantelando silenciosamente los argumentos a favor de GSAP, Framer Motion y todas las demás bibliotecas de animación JavaScript que has estado enviando a los usuarios. Aquí tienes las pruebas de rendimiento, los patrones de migración y la verdad honesta sobre lo que JavaScript todavía hace mejor.
El cementerio de JavaScript: cómo las animaciones de scroll nativas en CSS están volviendo obsoletas tus bibliotecas de animación
Cada pocos años, la plataforma web realiza un silencioso golpe de poder. Absorbió lo que hacíamos con jQuery. Se tragó lo que hacíamos con los hacks de Flexbox cargados de polyfills. Ahora va por tus animaciones de scroll — y esta vez tiene el hilo del Compositor de su lado.
La API de animaciones de scroll de CSS alcanzó estabilidad entre navegadores a finales de 2023 y desde entonces lleva en tu hoja de estilos, plenamente funcional y enormemente infrautilizada. Si todavía recurres a GSAP o Framer Motion cada vez que un cliente dice "que el scroll se vea bien", estás enviando kilobytes que los usuarios no pidieron para resolver problemas que CSS ahora resuelve de forma nativa.
Esto no es un ataque a las bibliotecas de animación. Es un ajuste de cuentas con los valores predeterminados.
Qué hacen (y qué no hacen) las animaciones de scroll de CSS
En esencia, la especificación de animaciones de scroll introduce dos nuevos tipos de línea de tiempo que reemplazan la progresión temporal predeterminada del documento con la posición de scroll como motor de la animación.
scroll()— vincula el progreso de una animación a la posición de scroll de un contenedor de desplazamiento específico (o el viewport raíz). Al desplazarte hacia abajo, la animación avanza.view()— vincula el progreso a la posición de un elemento dentro de su contenedor de scroll. La animación se ejecuta mientras el elemento entra y sale del área visible.
Estos se conectan a la Web Animations API existente o a declaraciones puras de animation en CSS mediante la propiedad animation-timeline:
.hero-title {
animation: fade-up linear;
animation-timeline: scroll(root);
animation-range: entry 0% entry 40%;
}
@keyframes fade-up {
from { opacity: 0; transform: translateY(40px); }
to { opacity: 1; transform: translateY(0); }
}
Eso es todo. Sin IntersectionObserver. Sin bucle requestAnimationFrame. Sin limpieza de event listeners. El navegador gestiona la interpolación de la línea de tiempo por completo.
Compatibilidad de navegadores a mediados de 2024: Chrome 115+, Edge 115+ y Firefox 110+ (con bandera hasta la versión 132, disponible en versión estable en 2024). Safari es el rezagado conocido — el soporte es parcial en Safari 17.2+ pero no está completo. Esto significa que aún se justifica una estrategia de mejora progresiva, pero la base de Chromium por sí sola cubre el 65–70% del tráfico global, lo cual es un umbral legítimo para la adopción en producción.
El escape con
@supportses tu mejor aliado:@supports (animation-timeline: scroll())te permite añadir comportamiento de scroll sobre una alternativa estática sin tocar una sola línea de JavaScript.
El argumento de rendimiento: tamaño del bundle, jank y capas compuestas
Aquí es donde el argumento se vuelve difícil de ignorar.
Peso del bundle
Las configuraciones de animación de scroll más comunes en la práctica se ven más o menos así:
| Enfoque | Peso adicional del bundle |
|---|---|
| GSAP Core + ScrollTrigger | ~67 KB minificado |
| Framer Motion (tree-shaken) | ~43 KB minificado |
| AOS (Animate on Scroll) | ~13 KB minificado |
| CSS Scroll-Driven nativo | 0 KB |
Cero. Está en el navegador. No estás enviando el runtime — estás declarando una intención, y la plataforma la ejecuta.
Para un sitio de marketing típico con cuatro o cinco efectos de scroll reveal, reemplazar las animaciones basadas en bibliotecas por CSS nativo supone una reducción legítima de 40–70 KB en el costo de parseo y ejecución de JavaScript. En un dispositivo Android de gama media con 4G, eso se traduce en una mejora medible del First Input Delay.
La ventaja del Compositor
Esta es la victoria menos comentada, pero más importante. Las animaciones JavaScript vinculadas al scroll — incluso las configuraciones bien escritas de GSAP — se ejecutan en el hilo principal a menos que uses explícitamente will-change, transform y opacity en condiciones cuidadosamente aisladas. El hilo principal también gestiona tus event listeners, los re-renders de tu framework y tus scripts de terceros.
Las animaciones de scroll de CSS que animan transform y opacity se ejecutan en el hilo del Compositor — un contexto de ejecución dedicado y aislado que no compite por el tiempo del hilo principal. El motor de animación del navegador gestiona la interpolación a nivel de hardware.
En los perfiles de rendimiento de Chrome DevTools, las animaciones GSAP vinculadas al scroll sobre propiedades transform aparecen sistemáticamente en el gráfico de llamas del hilo principal. ¿Los equivalentes nativos en CSS? No aparecen ahí en absoluto. Están completamente compuestos fuera de la imagen.
Traducido: Las animaciones de scroll nativas en CSS no solo reducen el tamaño del bundle — trasladan el trabajo de animación fuera del recurso más disputado en el rendimiento del navegador.
Cinco efectos de scroll que puedes reescribir en CSS puro hoy mismo
1. Fade-in al hacer scroll (el efecto más sobreutilizado en la historia de la web)
El patrón clásico de IntersectionObserver + toggle de clase. Reemplázalo por completo:
.card {
animation: reveal linear both;
animation-timeline: view();
animation-range: entry 10% entry 40%;
}
@keyframes reveal {
from { opacity: 0; transform: translateY(30px); }
to { opacity: 1; transform: translateY(0); }
}
2. Barra de progreso fija
Los indicadores de progreso de lectura de documentos — un caso de uso de scroll() tan perfecto que parece que la especificación fue escrita para ello:
#progress-bar {
position: fixed;
top: 0;
width: 100%;
height: 3px;
background: var(--accent);
transform-origin: left;
animation: grow-bar linear;
animation-timeline: scroll(root);
}
@keyframes grow-bar {
from { transform: scaleX(0); }
to { transform: scaleX(1); }
}
Sin estado, sin cálculos, sin event listeners. El navegador es el calculador de progreso del scroll.
3. Secciones hero con parallax
.hero-image {
animation: parallax linear;
animation-timeline: scroll(root);
animation-range: cover 0% cover 100%;
}
@keyframes parallax {
from { transform: translateY(0); }
to { transform: translateY(-25%); }
}
4. Carruseles de scroll horizontal impulsados por scroll vertical
Uno de los efectos más llamativos de las agencias — impulsar un translateX en una franja horizontal mientras el usuario hace scroll vertical — es completamente alcanzable con scroll() en un elemento wrapper fijado. El enfoque de CSS-Tricks usando sticky + scroll-timeline lo resuelve sin una sola línea de JavaScript.
5. Revelado de imágenes / animaciones clip-path al entrar
.image-reveal {
animation: clip-reveal linear both;
animation-timeline: view();
animation-range: entry 0% entry 50%;
}
@keyframes clip-reveal {
from { clip-path: inset(0 100% 0 0); }
to { clip-path: inset(0 0% 0 0); }
}
Cuándo las bibliotecas de animación JavaScript aún se justifican
Aquí viene la parte honesta. Las animaciones de scroll de CSS no son un reemplazo completo del ecosistema de animación JavaScript. Hay casos de uso claros y legítimos donde bibliotecas como GSAP siguen siendo la elección correcta:
Secuenciación compleja y líneas de tiempo. La API Timeline de GSAP para encadenar decenas de animaciones interdependientes con escalonamiento, callbacks y ramificación condicional no tiene equivalente en CSS. Si tu animación se parece a una secuencia de montaje cinematográfico, JavaScript gana.
Movimiento basado en física. La física de resortes, las curvas de momentum y las interacciones de arrastre — el dominio de useSpring de Framer Motion y bibliotecas como React Spring — no son reproducibles solo con funciones de easing de CSS.
Integración con Three.js y WebGL. Si tu scroll está impulsando la progresión de una escena 3D, uniformes de shaders o el movimiento de una cámara, necesitas JavaScript. Sin discusión.
Animación dinámica basada en datos. Cuando los parámetros de animación provienen de la entrada del usuario, respuestas de API o estado en tiempo de ejecución, necesitas JavaScript para calcularlos y aplicarlos. CSS no puede interpolar entre valores que no conoce en el momento del parseo.
Requisitos de navegadores antiguos. Si tu proyecto tiene tráfico significativo en Safari < 17 o necesita soporte para IE11 (por favor, abandona ese barco), las animaciones de scroll de CSS no son seguras como estrategia principal en producción.
La heurística práctica: Si tu animación de scroll puede describirse completamente en el momento del diseño y opera sobre propiedades animables con CSS, el CSS nativo debería ser tu opción predeterminada. Si necesita responder a datos, estado o comportamiento del usuario — recurre a JavaScript.
El patrón más amplio: CSS recuperando su territorio
Las animaciones de scroll son parte de un arco de una década en el que CSS se ha vuelto genuinamente capaz de realizar trabajo creativo de UI que JavaScript colonizó por necesidad y no por derecho.
- Custom Properties (2016) → eliminó la mayoría de los hacks de tematización basados en JS
position: sticky(2018) → acabó con la industria de plugins de cabeceras fijas- CSS Grid (2017) → enterró la mayor parte del JavaScript de maquetación
clamp()y container queries (2020–2022) → dejaron en gran medida obsoletos los cálculos JS basados en el viewport- Animaciones de scroll (2023) → la siguiente frontera conquistada
No es CSS presumiendo. Es la plataforma poniéndose al día con lo que los desarrolladores habían estado construyendo como soluciones provisionales. Cada capacidad que absorbe el navegador es cómputo que dejas de enviar, dependencias que dejas de actualizar y superficie de ataque que dejas de exponer.
Eligiendo la herramienta adecuada para un futuro CSS-first
La decisión madura aquí no es arrancar GSAP de cada proyecto. Es elevar tu umbral de justificación para recurrir a él.
Empieza desde CSS. Las animaciones de scroll, combinadas con @starting-style, transition-behavior y funciones de easing modernas como linear() con curvas personalizadas, cubren ahora la gran mayoría de los efectos de scroll en producción que las agencias y los equipos de producto realmente implementan.
Recurre a JavaScript cuando la animación sea dinámica, basada en física, secuenciada más allá de lo que las líneas de tiempo de CSS admiten, o necesite integrarse con el estado de la aplicación. En esos casos, GSAP y Framer Motion valen cada byte.
Pero para los scroll reveals de siempre, los indicadores de progreso, las capas de parallax y las animaciones de entrada que conforman el 80% de los encargos de "que se sienta premium"? Tu hoja de estilos llamó. Dijo que ya lo tiene cubierto.
El cementerio de JavaScript no se llena de la noche a la mañana — pero hay una tumba recién cavada con "biblioteca de animaciones vinculadas al scroll" en la lápida. Si la llenarás o no depende enteramente de si has revisado últimamente lo que CSS puede hacer.