La decisión honesta: cuándo compensa

Después de tres niveles de sintaxis, rangos y fallbacks, queda la pregunta que de verdad importa y que ninguna documentación contesta: ¿merece la pena? La respuesta no es sí ni no, es un procedimiento con cuatro preguntas que se hacen en orden y que casi siempre terminan en la misma conclusión práctica: adopta, pero solo para lo que es realmente decorativo, y sin polyfill.

Las cuatro preguntas, en orden

Primera: ¿el resultado es una interpolación de propiedades? Si lo que quieres es que algo cambie de valor de forma continua según el scroll, sí. Si lo que quieres es disparar una acción —cargar datos, reproducir un vídeo, registrar una métrica— no, y lo que necesitas es IntersectionObserver. Esta pregunta descarta más casos de los que parece, porque mucha gente llega a las timelines buscando “detectar cuándo un elemento entra en pantalla”, que es otra cosa.

Segunda: ¿el componente sigue teniendo sentido sin el efecto? Es el análisis de la lección anterior. Si la respuesta es sí, sigue. Si es no, decide antes si el componente se oculta o se sustituye donde no funciona; no adoptes hasta haber decidido eso.

Tercera: ¿el efecto es percibible como valor o solo como adorno? Esta es la pregunta incómoda. Un revelado de párrafos en un artículo largo no aporta nada y resta legibilidad. Un movimiento que hace evidente la relación entre dos elementos sí aporta. Si no sabes contestar, la respuesta es adorno.

Cuarta: ¿el coste de la mejora progresiva es asumible? Con las timelines de scroll casi siempre lo es —dos líneas y un @supports— y por eso la respuesta habitual es sí. Deja de serlo cuando el efecto es tan estructural que el fallback tendría que ser un rediseño.

El resultado del procedimiento se resume así:

Las tres alternativas cuando la respuesta es no

IntersectionObserver para los efectos secundarios. Es la herramienta correcta para “cuando esto entre en pantalla, haz algo”: cargar contenido, marcar como leído, activar una sección del índice, reproducir un vídeo. Funciona en los tres motores desde hace años, corre fuera del hilo principal para la detección, y no tiene ninguna de las asimetrías de eventos de las timelines.

const observador = new IntersectionObserver(
  (entradas) => {
    for (const entrada of entradas) {
      if (!entrada.isIntersecting) continue;
      entrada.target.classList.add('visto');
      observador.unobserve(entrada.target);   // una sola vez
    }
  },
  { rootMargin: '0px 0px -20% 0px', threshold: 0.15 }
);

document.querySelectorAll('.revelar').forEach((el) => observador.observe(el));

Ese unobserve es la diferencia de fondo con una timeline: expresa “esto ocurre una vez y no se deshace”, que es un requisito que las timelines por definición no pueden satisfacer. Combinado con una transición CSS sobre la clase .visto, produce un revelado que funciona en los tres motores, no revierte al subir, y cuesta unas diez líneas.

position: sticky para lo que parece scroll y no lo es. Una parte considerable de los efectos que la gente implementa con scroll son en realidad posicionamiento. Un elemento que se queda fijo mientras su sección pasa, una tabla con cabecera pegada, un índice lateral que acompaña: todo eso es sticky, es universal, y es infinitamente más barato.

Una librería, si el proyecto ya la tiene. Si el proyecto usa GSAP —que desde abril de 2025 es gratuito por completo, plugins incluidos— ScrollTrigger cubre los tres motores con una sola implementación y resuelve casos que las timelines nativas no cubren: pin real, scrub con suavizado, snap entre secciones. La decisión ahí no es técnica sino de arquitectura: añadir una librería de animación a un proyecto que no la tiene, solo para cubrir un motor, es un coste mucho mayor que el polyfill. Pero si ya está cargada por otros motivos, usarla es lo sensato.

Los tres antipatrones

Merece la pena nombrarlos porque son la causa de que “sitio con animaciones de scroll” sea, para mucha gente, sinónimo de sitio insufrible.

El secuestro del scroll. Cualquier técnica que haga que la página no se mueva la distancia que el usuario ha pedido. Con timelines nativas no puedes hacerlo —no tienen acceso a la posición del scroll, solo la leen— y eso es una de sus mejores propiedades. En cuanto se añade JavaScript para “suavizar”, el riesgo aparece: un scroll suavizado es un scroll secuestrado, y rompe la búsqueda en página, la navegación por teclado y los lectores de pantalla.

La animación que retrasa la lectura. Cada elemento que aparece progresivamente es un elemento que durante un rato no se puede leer. En un artículo, multiplicado por cincuenta párrafos, es una experiencia de lectura peor sin ninguna contrapartida.

El paralaje sin propósito. Mover cosas a velocidades distintas produce sensación de profundidad y también produce malestar vestibular en una fracción no despreciable de la población. Si el paralaje no comunica nada —y casi nunca comunica nada— es coste puro, y la capa de prefers-reduced-motion no lo arregla, solo lo reduce para quien ha sabido configurarlo.

La recomendación con la que quedarse

Si tuvieras que reducir estos tres niveles a una política de equipo, cabría en cinco líneas:

1. Usa timelines de scroll para efectos decorativos y reversibles: revelados sutiles, paralajes discretos, cabeceras que se compactan, sombras de borde.
2. Escribe siempre el estado final —o el de reposo— en la regla base, y la animación dentro de un @supports.
3. Usa IntersectionObserver para todo lo que sea un efecto secundario o que no deba revertirse.
4. No cargues el polyfill salvo que la animación sea el producto y hayas medido el impacto.
5. Trata el navegador sin soporte como el caso normal, no como la excepción: si el sitio no se defiende sin animaciones, el problema no es el navegador.

Ese quinto punto es el que resume el nivel entero, y tiene una virtud que va más allá de este tema concreto: sirve igual para las animaciones dirigidas por scroll de hoy que para cualquier capacidad de plataforma que adoptes antes de que sea universal.