Scroll-Driven Animations nativas en CSS: el fin de IntersectionObserver en 2026

Si tu sitio carga 80 KB de JavaScript solo para animar elementos al hacer scroll — con IntersectionObserver, AOS.js, ScrollTrigger de GSAP o WOW.js — 2026 es el año en que eso deja de tener sentido. Las scroll-driven animations nativas de CSS llegan con más del 90% de soporte en navegadores, cero JavaScript en el hilo principal, y un impacto directo en INP que ningún polyfill puede igualar.

En Mintec hemos migrado sistemas de animación scroll en tres proyectos durante los primeros meses de 2026. Dos portafolios visuales y una plataforma editorial. Los tres compartían un patrón: docenas de observadores de intersección, detectando cuándo los elementos entraban al viewport para disparar animaciones de entrada. Los tres terminaron con menos JavaScript, mejor INP, y animaciones que se sienten igual o mejor que antes.

Este artículo documenta qué son las scroll-driven animations, cómo se comparan con las alternativas tradicionales, y el framework que usamos para decidir cuándo migrar.

Qué son las CSS scroll-driven animations (y por qué importan)

Las scroll-driven animations son un módulo CSS que permite que el progreso de una animación se controle por la posición de scroll del usuario, no por el tiempo. En lugar de escribir:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
    }
  });
});

Escribes:

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

.card {
  animation: fade-in linear;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Sin JavaScript. Sin observadores. Sin librerías. El navegador maneja todo en el hilo del compositor, fuera del hilo principal. Eso significa que la animación no compite con el JavaScript de la página, no dispara re-layouts costosos, y no afecta al INP.

El módulo se compone de tres conceptos clave:

• animation-timeline: la propiedad que vincula una animación a una línea de tiempo de scroll en lugar de una línea de tiempo por tiempo.
• scroll(): crea una línea de tiempo anónima basada en el progreso de scroll de un contenedor o del viewport.
• view(): crea una línea de tiempo basada en la visibilidad de un elemento dentro de su contenedor de scroll.

Además, puedes definir líneas de tiempo nombradas con scroll-timeline-name y scroll-timeline-axis, y reutilizarlas en múltiples animaciones.

Comparativa: scroll-driven CSS vs. IntersectionObserver vs. GSAP ScrollTrigger

Para entender cuándo merece la pena migrar, necesitas ver los números reales. Probamos los tres enfoques en el mismo proyecto: un portafolio con 12 secciones animadas al scroll.

Los datos son de nuestro proyecto de migración para una plataforma editorial con tráfico de 200K visitas/mes. El cambio de IntersectionObserver a scroll-driven CSS redujo el JavaScript de la página en un 12% (de 180 KB a 158 KB gzipped) y mejoró el INP de "Needs Improvement" (320ms) a "Good" (148ms). No porque scroll-driven sea mágicamente más rápido, sino porque quitamos 24 IntersectionObservers que se registraban en cada carga de página.

Lo que aprendimos migrando tres proyectos

Cada proyecto nos enseñó algo diferente.

Proyecto 1: Portafolio de estudio creativo (Barcelona). 8 secciones con animaciones de entrada, un parallax sutil en el hero, y una galería con efecto masonry. Usaban AOS.js + IntersectionObserver. La migración tomó 3 horas. Resultado: 28 KB menos de JavaScript, INP de 198ms a 112ms. La sorpresa fue que las animaciones se sintieron más fluidas porque el navegador no tenía que procesar callbacks JS en cada frame.

Proyecto 2: Plataforma editorial con 200K visitas/mes. 12 componentes con animaciones scroll, más una barra de progreso de lectura. Usaban vanilla IntersectionObserver. La migración fue más compleja porque algunos componentes tenían cadenas de animación (entrada → pausa → desplazamiento → salida). Las scroll-driven animations nativas no soportan cadenas de animación complejas de forma directa — tuvimos que combinar animation-range con animation-delay para simularlas. En 3 de los 12 casos, mantener IntersectionObserver fue la decisión correcta.

Proyecto 3: Blog técnico con documentación. Animaciones mínimas pero un indicador de progreso de lectura (la barra que muestra cuánto llevas leído). Con IntersectionObserver era ~60 líneas de JS para calcular la posición relativa al artículo. Con CSS scroll-driven, fueron 8 líneas de CSS usando animation-timeline: scroll(root) y midiendo el progreso del scroll del body. La implementación más elegante de las tres.

Cuándo NO usar CSS scroll-driven animations

El soporte de Firefox es la limitación más importante. Mientras Firefox no libere el soporte sin flag —actualmente accesible en Firefox Nightly y beta, pero no en stable— aproximadamente el 3-4% de tus usuarios globales no verán las animaciones. Si tu audiencia tiene una proporción alta de Firefox (algunos mercados europeos, usuarios técnicos), necesitas progressive enhancement: que el contenido sea funcional sin animaciones.

Otros casos donde recomendamos mantener IntersectionObserver o GSAP:

1. Cadenas de animación complejas. Si necesitas que A → B → C ocurra en secuencia con distintos triggers de scroll, CSS scroll-driven no tiene una sintaxis limpia para eso. animation-range cubre progresión lineal, no bifurcaciones.

2. Animaciones condicionales. Si la animación depende del estado de un componente (por ejemplo, "si el usuario ya ha visto esta sección antes, no la animes otra vez"), necesitas JavaScript para gestionar ese estado.

3. Interacciones mixtas (scroll + click + hover). Si un elemento cambia su comportamiento según si el usuario hizo scroll, click o hover, un solo animation-timeline no basta.

4. Soporte legacy extremo. Si tu proyecto requiere Internet Explorer o navegadores muy antiguos (obsoleto para la mayoría de proyectos en 2026, pero relevante para ciertos sectores).

Framework de decisión para migrar

Usamos este árbol de decisión en cada proyecto:

¿El proyecto usa animaciones basadas en scroll?
  ├── Sí → ¿Son animaciones de entrada (fade-in, slide-up)?
  │         ├── Sí → MIGRAR (scroll-driven CSS gana siempre)
  │         └── No → ¿Es parallax o progreso de lectura?
  │                  ├── Sí → MIGRAR (best-in-class para estos casos)
  │                  └── No → ¿Son cadenas con condiciones?
  │                           ├── Sí → MANTENER IntersectionObserver/GSAP
  │                           └── No → MIGRAR con progressive enhancement
  └── No → No toques nada

En nuestra experiencia, aproximadamente el 70% de los patrones de animación scroll pueden migrarse directamente a CSS scroll-driven. El 20% requiere progressive enhancement (CSS + fallback JS). El 10% restante —cadenas complejas, animaciones condicionales, interacciones mixtas— debe quedarse en JavaScript.

Recursos para empezar

Si quieres probar scroll-driven animations hoy, el MDN sobre scroll-driven animations es la referencia oficial. La guía de Web Perf Clinic tiene ejemplos prácticos con métricas reales de performance.

En Mintec hemos escrito extensamente sobre cómo las nuevas capacidades nativas del navegador están redefiniendo el desarrollo frontend. Si te interesa este tema, te recomendamos:

• Nuestro artículo sobre Container Queries y @scope — el otro módulo CSS que cambió cómo construimos componentes en 2026
• Cómo depuramos INP en sitios multimedia usando LoAF y scheduler.yield()
• Por qué HTML nativo y accesibilidad sin ARIA es el estándar que todos deberíamos seguir en 2026
• El dilema del video hero y cómo equilibrar diseño visual con rendimiento

La dirección es clara: el navegador está incorporando capacidades que antes requerían librerías JavaScript. Scroll-driven animations, container queries, view transitions, cascade layers — cada uno reduce la dependencia de JavaScript y acerca el desarrollo web a lo que siempre debería haber sido: escribir declarativamente lo que queremos, y que el navegador se encargue del resto.