Animaciones CSS con animation-timeline

Posted on by marta

Las animaciones CSS han dejado de ser simples efectos decorativos para convertirse en una parte importante de la experiencia de usuario. Durante mucho tiempo, cuando queríamos crear animaciones vinculadas al desplazamiento de la página, lo habitual era recurrir a JavaScript: escuchar el evento de scroll, calcular la posición del usuario, añadir clases dinámicamente y sincronizar cada movimiento con el avance de la navegación.

Ese enfoque sigue siendo válido en muchos casos, pero también puede añadir complejidad, afectar al rendimiento y hacer que una interacción visual sencilla dependa de demasiado código. Por eso resulta tan interesante la llegada de animation-timeline en CSS, una propiedad que permite controlar el progreso de una animación a partir de una línea de tiempo distinta al tiempo tradicional.

Dicho de una forma sencilla: con animation-timeline, una animación ya no tiene por qué avanzar únicamente durante una cantidad fija de segundos. También puede avanzar según el scroll de la página, el desplazamiento de un contenedor o la visibilidad de un elemento dentro del viewport.

Esto abre la puerta a una nueva generación de animaciones CSS modernas, mucho más conectadas con la interacción real del usuario. Podemos crear barras de progreso de lectura, revelados suaves de contenido, efectos de entrada, transformaciones progresivas o pequeñas microinteracciones sin depender siempre de JavaScript.

En este artículo vamos a ver qué es animation-timeline CSS, cómo funciona una CSS animation timeline, qué relación tiene con scroll timeline CSS y cómo utilizar esta técnica con criterio, accesibilidad y buen rendimiento.

Qué es animation-timeline en CSS

La propiedad animation-timeline permite definir qué línea de tiempo controla el progreso de una animación CSS. En una animación tradicional, lo habitual es trabajar con una duración concreta:

.elemento {
  animation: aparecer 1s ease-out forwards;
}

En este ejemplo, la animación empieza, avanza durante un segundo y termina. Es una animación basada en tiempo.

Con animation-timeline, la lógica cambia. La animación puede avanzar en función de otro tipo de timeline, por ejemplo, la visibilidad del elemento en pantalla:

.elemento {
  animation: aparecer linear both;
  animation-timeline: view();
}

Aquí ya no estamos diciendo que la animación dure un segundo. Estamos indicando que el avance de la animación se relaciona con la presencia del elemento dentro del área visible del navegador.

Esta diferencia es importante porque permite crear efectos mucho más naturales. La animación responde a lo que hace el usuario, no a un temporizador fijo.

Si estás empezando a trabajar con movimiento en interfaces, te recomiendo complementar este tema con la guía sobre animaciones CSS desde cero, donde se explican los fundamentos antes de pasar a técnicas más avanzadas.

De las animaciones temporales a las animaciones guiadas por scroll

Las animaciones CSS clásicas funcionan muy bien para muchos casos. Por ejemplo, un botón puede cambiar de color en 300ms, una tarjeta puede aparecer en 600ms o un icono puede rotar suavemente al hacer hover.

Ese tipo de animaciones siguen siendo útiles, especialmente cuando queremos responder a una acción concreta. Sin embargo, hay situaciones en las que una duración fija no representa bien la interacción.

Pensemos en una barra de progreso de lectura. No queremos que avance automáticamente durante dos segundos. Queremos que avance según el usuario recorre el contenido. Lo mismo ocurre con una sección que se revela al entrar en pantalla: tiene más sentido que la animación dependa de su posición en el viewport que de una duración fija al cargar la página.

Ahí entran las scroll-driven animations, es decir, animaciones impulsadas por el scroll. En este modelo, el desplazamiento controla el progreso de la animación. Si el usuario baja, la animación avanza. Si sube, retrocede. Si se detiene, la animación también se detiene.

Para profundizar en este concepto, puedes enlazar este artículo con una guía específica sobre scroll-driven animations: qué son y cómo usarlas, ya que ambos temas están muy relacionados.

Conceptos clave antes de escribir código

Antes de usar animation-timeline, conviene tener claros algunos conceptos:

Timeline: es la línea de tiempo que controla el progreso de una animación. Puede estar basada en tiempo, scroll o visibilidad.

Scroll progress timeline: es una línea de tiempo basada en el progreso de desplazamiento de un contenedor.

View progress timeline: es una línea de tiempo basada en la visibilidad de un elemento dentro del área visible.

scroll(): función que crea una timeline anónima vinculada al scroll de un contenedor.

view(): función que crea una timeline basada en la visibilidad del propio elemento animado.

animation-range: propiedad complementaria que permite definir en qué tramo de la timeline debe ejecutarse la animación.

Estos términos pueden sonar técnicos al principio, pero se entienden mucho mejor cuando los vemos aplicados a ejemplos reales.

Sintaxis básica de animation-timeline

La estructura habitual combina tres partes: una animación definida con @keyframes, la propiedad animation y la propiedad animation-timeline.

@keyframes aparecer {
  from {
    opacity: 0;
    transform: translateY(2rem);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.elemento {
  animation: aparecer linear both;
  animation-timeline: view();
}

En este caso, @keyframes define los estados de la animación. La propiedad animation indica qué animación se aplica, con qué interpolación y con qué comportamiento de relleno. Finalmente, animation-timeline: view(); indica que la animación se vincula a la visibilidad del elemento.

Un detalle importante: conviene declarar animation-timeline después del shorthand animation. Esto se debe a que animation puede resetear algunas propiedades relacionadas con la animación. Si escribimos primero animation-timeline y después animation, es posible que la timeline no se aplique como esperamos.

La forma recomendada sería:

.card {
  animation: fade-in linear both;
  animation-timeline: view();
}

Y no esta:

.card {
  animation-timeline: view();
  animation: fade-in linear both;
}

Este pequeño detalle puede evitar errores difíciles de detectar.

Ejemplo 1: barra de progreso de lectura con scroll()

Uno de los usos más claros de animation-timeline CSS es crear una barra de progreso que avance a medida que el usuario hace scroll por un artículo.

<div class="reading-progress"></div>

.reading-progress {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 0.35rem;
  transform-origin: left center;
  transform: scaleX(0);
  z-index: 9999;

  animation: progress linear both;
  animation-timeline: scroll(root block);
}

@keyframes progress {
  to {
    transform: scaleX(1);
  }
}

En este ejemplo, la animación progress modifica la escala horizontal de la barra. Al principio, scaleX(0) hace que la barra no se vea. Al final, scaleX(1) hace que ocupe todo el ancho disponible.

La clave está en esta línea:

animation-timeline: scroll(root block);

root indica que la timeline se basa en el scroll principal del documento. block indica que se tiene en cuenta el eje de bloque, que normalmente corresponde al desplazamiento vertical en páginas escritas de arriba hacia abajo.

Este tipo de efecto es muy útil en artículos largos, documentación técnica, tutoriales y páginas editoriales. Aporta una referencia visual clara sin interrumpir la lectura.

Además, desde el punto de vista del rendimiento, es preferible animar transform en lugar de modificar directamente el ancho con width. Si quieres profundizar en este criterio, puedes leer el artículo sobre por qué animar transform y opacity antes que width o height.

Ejemplo 2: revelar tarjetas al entrar en pantalla con view()

Otro uso habitual de animation-timeline es animar elementos cuando entran en el viewport. Antes, este patrón solía resolverse con JavaScript y la API Intersection Observer. Ahora, en muchos casos, podemos hacerlo solo con CSS.

<section class="grid">
  <article class="card">Contenido 1</article>
  <article class="card">Contenido 2</article>
  <article class="card">Contenido 3</article>
</section>

.card {
  opacity: 0;
  transform: translateY(3rem) scale(0.96);

  animation: reveal-card linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 35%;
}

@keyframes reveal-card {
  to {
    opacity: 1;
    transform: translateY(0) scale(1);
  }
}

Aquí la animación no se ejecuta simplemente al cargar la página. Se vincula a la visibilidad de cada .card. Cuando el elemento entra en pantalla, la animación avanza.

La propiedad animation-range permite ajustar el tramo en el que se desarrolla la animación:

animation-range: entry 0% cover 35%;

Esto indica que la animación empieza cuando el elemento entra en el área visible y progresa durante una parte concreta de su recorrido. El resultado es una aparición más controlada, sin movimientos demasiado bruscos ni animaciones innecesariamente largas.

Este patrón funciona muy bien para listados de proyectos, bloques de servicios, secciones de landing page o tarjetas de contenido.

Ejemplo 3: una timeline con nombre usando scroll-timeline

Además de usar timelines anónimas con scroll() o view(), también podemos crear timelines con nombre. Esto resulta útil cuando varios elementos deben depender del mismo contenedor de scroll o cuando queremos que el CSS sea más explícito.

<div class="scroller">
  <div class="content">
    <div class="box"></div>
  </div>
</div>

.scroller {
  height: 400px;
  overflow-y: auto;
  scroll-timeline: --panel-scroll block;
}

.box {
  width: 120px;
  height: 120px;

  animation: rotate-box linear both;
  animation-timeline: --panel-scroll;
}

@keyframes rotate-box {
  to {
    transform: rotate(360deg);
  }
}

En este ejemplo, .scroller define una timeline llamada --panel-scroll. Después, .box utiliza esa timeline para controlar su animación.

Este enfoque puede ser más claro en proyectos grandes, porque permite nombrar la timeline y reutilizarla en diferentes elementos.

Diferencia entre scroll() y view()

Aunque scroll() y view() se utilizan con animation-timeline, no sirven exactamente para lo mismo.

Cuándo usar scroll()

Conviene usar scroll() cuando la animación depende del progreso general de desplazamiento de un contenedor.

Algunos casos habituales son:

  • Barras de progreso de lectura.
  • Indicadores de avance en una página.
  • Animaciones vinculadas al scroll completo de un contenedor.
  • Transformaciones progresivas desde el inicio hasta el final de una sección.

Ejemplo:

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

En este caso, la animación se controla mediante el scroll global de la página.

Cuándo usar view()

Conviene usar view() cuando la animación depende de la visibilidad de un elemento concreto.

Algunos casos habituales son:

  • Tarjetas que aparecen al entrar en pantalla.
  • Imágenes que se revelan progresivamente.
  • Títulos que se desplazan suavemente al hacerse visibles.
  • Elementos decorativos que reaccionan cuando pasan por el viewport.

Ejemplo:

.image {
  animation: reveal linear both;
  animation-timeline: view();
  animation-range: entry 10% cover 40%;
}

En este caso, la animación se controla por la relación entre el elemento y el área visible.

Una regla práctica para decidir

Puedes quedarte con esta idea:

Si quieres animar algo según el avance total del scroll, usa scroll().

Si quieres animar algo según cuándo aparece en pantalla, usa view().

Esta diferencia ayuda mucho a elegir la solución correcta y evita complicar el CSS sin necesidad.

Buenas prácticas para usar animaciones CSS modernas

animation-timeline es una herramienta potente, pero no conviene usarla sin criterio. Una animación puede mejorar mucho una interfaz, pero también puede empeorarla si añade ruido, distrae o dificulta la lectura.

Prioriza transform y opacity

Para conseguir animaciones más fluidas, es recomendable priorizar propiedades como:

transform
opacity

Estas propiedades suelen ser más eficientes que animar width, height, top, left, margin o padding, porque reducen el riesgo de provocar recálculos de layout costosos.

Por ejemplo, para una barra de progreso es mejor usar:

transform: scaleX();

en lugar de animar directamente:

width

Visualmente pueden parecer soluciones parecidas, pero a nivel de rendimiento no siempre lo son. Este criterio también se relaciona con otras buenas prácticas que puedes ampliar en el artículo sobre animaciones CSS y rendimiento.

Usa animaciones con intención

Una animación debería cumplir una función concreta. Puede guiar la atención, reforzar una jerarquía visual, explicar una relación entre elementos o hacer más fluida una transición.

Lo que conviene evitar son las animaciones gratuitas. Si cada bloque entra con un efecto exagerado, si todo se mueve al mismo tiempo o si el scroll se vuelve incómodo, la experiencia se resiente.

Una buena animación CSS moderna debería sentirse natural. Está ahí para acompañar, no para robar protagonismo.

Si tienes dudas sobre cuándo aplicar movimiento y cuándo simplificar, puedes enlazar este tema con el artículo sobre cuándo usar animaciones CSS y cuándo evitarlas.

Respeta prefers-reduced-motion

No todas las personas disfrutan de las animaciones. Algunas pueden experimentar incomodidad, mareo o fatiga visual con movimientos constantes. Por eso es importante respetar la preferencia del sistema prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 1ms !important;
    animation-iteration-count: 1 !important;
    scroll-behavior: auto !important;
  }

  .card,
  .image,
  .section-title {
    animation-timeline: auto;
    transform: none;
    opacity: 1;
  }
}

Este bloque reduce o desactiva animaciones para las personas que han indicado esa preferencia en su sistema operativo o navegador.

La accesibilidad no es un añadido final. Es parte de una buena implementación front-end. Por eso, cualquier técnica moderna de animación debería plantearse siempre desde la mejora progresiva y el respeto a las preferencias del usuario.

Añade fallbacks con @supports

Como animation-timeline es una característica moderna, conviene ofrecer una experiencia alternativa en navegadores que no la soporten completamente.

Una buena forma de hacerlo es utilizar @supports:

.card {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .card {
    opacity: 0;
    transform: translateY(2rem);
    animation: reveal linear both;
    animation-timeline: view();
    animation-range: entry 0% cover 35%;
  }
}

Así nos aseguramos de que, si el navegador no entiende animation-timeline, el contenido siga siendo visible y usable.

Este punto es fundamental: el contenido nunca debería depender de una animación para poder verse.

Errores frecuentes al usar animation-timeline

Aunque la sintaxis no es excesivamente compleja, hay algunos errores habituales que conviene evitar.

Declarar animation-timeline antes de animation

Como el shorthand animation puede resetear algunas propiedades, es mejor declarar animation-timeline después.

Correcto:

.element {
  animation: reveal linear both;
  animation-timeline: view();
}

Incorrecto:

.element {
  animation-timeline: view();
  animation: reveal linear both;
}

Este error puede hacer que la timeline no se aplique correctamente y que la animación se comporte como una animación temporal tradicional.

Olvidar que sigue haciendo falta @keyframes

animation-timeline no crea una animación por sí sola. Solo define qué timeline controla su progreso. Para que haya un cambio visual, necesitamos seguir usando @keyframes.

@keyframes fade-in {
  to {
    opacity: 1;
  }
}

Sin una animación definida, no hay nada que ejecutar.

Animar demasiados elementos a la vez

Aunque CSS permita crear efectos muy llamativos, conviene limitar la cantidad de elementos animados simultáneamente. Una página con demasiadas animaciones vinculadas al scroll puede sentirse pesada, especialmente en dispositivos móviles o equipos con menos potencia.

La recomendación práctica es empezar con pocos efectos, probar la experiencia real y ajustar según el contexto.

No probar en diferentes navegadores

Las animaciones CSS modernas avanzan rápido, pero no siempre llegan igual a todos los navegadores. Antes de utilizar animation-timeline en producción, conviene comprobar la compatibilidad, probar en dispositivos reales y asegurar que el contenido sigue siendo accesible si la animación no se ejecuta.

Ejemplo completo: sección editorial animada con CSS

Veamos ahora un ejemplo más completo. Imaginemos una sección editorial con texto e imagen.

<section class="feature">
  <div class="feature__content">
    <p class="feature__eyebrow">CSS moderno</p>
    <h2 class="feature__title">Animaciones vinculadas al scroll</h2>
    <p class="feature__text">
      Crea efectos progresivos sin depender de JavaScript para cada interacción visual.
    </p>
  </div>

  <img class="feature__image" src="imagen.jpg" alt="Interfaz con animación CSS">
</section>

.feature {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 3rem;
  align-items: center;
  padding: 6rem 2rem;
}

.feature__content,
.feature__image {
  opacity: 0;
  transform: translateY(3rem);
  animation: reveal-feature linear both;
  animation-timeline: view();
  animation-range: entry 10% cover 40%;
}

.feature__image {
  transform: translateY(3rem) scale(0.96);
}

@keyframes reveal-feature {
  to {
    opacity: 1;
    transform: translateY(0) scale(1);
  }
}

@media (max-width: 768px) {
  .feature {
    grid-template-columns: 1fr;
  }
}

Este ejemplo crea una entrada suave para el contenido y la imagen. La animación está vinculada a la visibilidad de cada elemento, no al momento de carga de la página.

El resultado es una experiencia más natural: el contenido aparece cuando tiene sentido, no antes.

Mejora progresiva aplicada al ejemplo

Para que el ejemplo sea más robusto, podemos envolver la parte avanzada con @supports:

.feature__content,
.feature__image {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .feature__content,
  .feature__image {
    opacity: 0;
    transform: translateY(3rem);
    animation: reveal-feature linear both;
    animation-timeline: view();
    animation-range: entry 10% cover 40%;
  }
}

De esta manera, los navegadores sin soporte verán el contenido de forma normal. Los navegadores compatibles disfrutarán de la animación.

Este enfoque es muy recomendable para proyectos reales, porque combina innovación con estabilidad.

SEO, UX y rendimiento: por qué importan estas animaciones

Desde el punto de vista SEO, una animación no posiciona por sí sola. Google no va a premiar una página únicamente porque utilice animation-timeline CSS. Sin embargo, una buena experiencia de usuario sí puede influir indirectamente en cómo se percibe el contenido.

Una página clara, fluida, accesible y agradable puede favorecer la lectura, reducir la fricción y ayudar a que las personas permanezcan más tiempo interactuando con el contenido. Pero para lograrlo, las animaciones deben estar al servicio del mensaje.

En artículos técnicos, por ejemplo, una barra de progreso puede ayudar al lector a orientarse. En un portfolio, una animación de entrada puede presentar los proyectos de forma más cuidada. En una landing page, una transición sutil puede reforzar la narrativa visual.

La clave está en usar las animaciones como parte del diseño, no como decoración añadida al final.

Criterios para decidir si una animación aporta valor

Antes de implementar un efecto con animation-timeline, puedes hacerte estas preguntas:

  • ¿Ayuda a entender mejor la interfaz?
  • ¿Refuerza la jerarquía visual?
  • ¿Acompaña una acción del usuario?
  • ¿Funciona bien en móvil?
  • ¿Sigue siendo usable si la animación no se ejecuta?
  • ¿Respeta las preferencias de accesibilidad?

Si la respuesta es sí, probablemente la animación tenga sentido. Si la respuesta es no, quizá conviene simplificar.

Preguntas frecuentes sobre animation-timeline CSS

¿Qué es animation-timeline en CSS?

animation-timeline es una propiedad CSS que permite indicar qué línea de tiempo controla una animación. En lugar de depender únicamente del paso del tiempo, una animación puede progresar según el scroll de la página, el scroll de un contenedor o la visibilidad de un elemento.

Esto permite crear efectos como barras de progreso, revelados al entrar en pantalla o animaciones vinculadas al desplazamiento sin tener que recurrir siempre a JavaScript.

¿Cuál es la diferencia entre scroll() y view()?

scroll() se utiliza cuando queremos que la animación dependa del progreso de desplazamiento de un contenedor. Por ejemplo, una barra que se llena a medida que avanzamos por un artículo.

view() se utiliza cuando queremos que la animación dependa de la visibilidad de un elemento. Por ejemplo, una tarjeta que aparece progresivamente cuando entra en el viewport.

En resumen: scroll() mira el avance del scroll; view() mira la presencia del elemento en la zona visible.

¿Es recomendable usar animation-timeline en producción?

Sí, puede ser recomendable, pero con cuidado. Lo ideal es aplicarlo con mejora progresiva, revisar compatibilidad, usar @supports, mantener el contenido visible aunque la animación no funcione y respetar prefers-reduced-motion.

También conviene probar en dispositivos reales y evitar que las animaciones sean necesarias para comprender o utilizar la página.

Una forma más natural de animar la web

animation-timeline representa un paso importante en la evolución de CSS. Nos permite crear animaciones más conectadas con la interacción real del usuario, especialmente en experiencias basadas en scroll.

La gran ventaja no es solo técnica. También es conceptual. En lugar de pensar en animaciones como eventos aislados que ocurren durante una cantidad fija de segundos, podemos diseñarlas como respuestas progresivas al movimiento, a la lectura y a la presencia del contenido en pantalla.

Esto hace que las interfaces puedan sentirse más vivas, pero también más coherentes. Una barra que avanza mientras leemos, una imagen que se revela cuando llega su momento o una tarjeta que aparece suavemente al entrar en el viewport son detalles que pueden mejorar la experiencia sin sobrecargarla.

Como ocurre con cualquier recurso visual, la clave está en el equilibrio. No se trata de animar por animar, sino de utilizar las herramientas modernas de CSS para construir interfaces más claras, accesibles y agradables.

Si se usa con intención, animation-timeline CSS puede convertirse en una pieza muy valiosa dentro del conjunto de animaciones CSS modernas. Permite reducir dependencias innecesarias de JavaScript, escribir código más declarativo y crear experiencias visuales que acompañan al usuario de forma natural.

En definitiva, las animaciones con animation-timeline no son solo una novedad técnica. Son una invitación a pensar el movimiento en la web de una manera más fluida, contextual y humana.

QA manual vs testing automatizado: cuándo usar cada enfoque

Posted on by marta

Cuando un equipo empieza a prestar más atención a la calidad del software, es habitual que surja una pregunta: ¿conviene apostar por el QA manual o por el testing automatizado?

La respuesta no consiste en elegir un único enfoque. Las pruebas manuales y las pruebas automatizadas cumplen funciones diferentes y, cuando se combinan correctamente, permiten detectar más errores, reducir riesgos y publicar nuevas versiones con mayor confianza.

El QA manual aporta observación, interpretación y capacidad para explorar situaciones inesperadas. El testing automatizado, en cambio, ofrece velocidad, repetibilidad y la posibilidad de ejecutar cientos de comprobaciones sin intervención constante de una persona.

El problema aparece cuando se intenta automatizar absolutamente todo o, en el extremo contrario, cuando el equipo depende de comprobaciones manuales para cada nueva entrega. Ambas decisiones pueden ralentizar el desarrollo y aumentar el coste de mantenimiento.

En este artículo veremos las diferencias entre QA manual y testing automatizado, cuándo utilizar cada enfoque, qué pruebas merece la pena automatizar y cómo diseñar una estrategia equilibrada para un proyecto real.

Qué es el QA manual

El QA manual consiste en comprobar una aplicación mediante la interacción directa de una persona. El profesional de calidad navega por las pantallas, completa formularios, introduce datos, reproduce escenarios y compara el resultado obtenido con el comportamiento esperado.

Aunque se denomine “manual”, esto no significa que se trate de un proceso improvisado. Una estrategia profesional de pruebas manuales puede incluir:

  • Planes de prueba.
  • Casos de prueba documentados.
  • Listas de comprobación.
  • Criterios de aceptación.
  • Matrices de dispositivos y navegadores.
  • Registro y seguimiento de incidencias.
  • Sesiones de testing exploratorio.

La principal diferencia frente a la automatización es que la ejecución depende del criterio de una persona. Un script puede comprobar que un botón responde al hacer clic. Un tester, además, puede valorar si su etiqueta es comprensible, si su ubicación genera dudas o si el resultado de la acción se comunica correctamente.

Qué puede detectar una prueba manual

Las pruebas manuales resultan especialmente útiles para detectar problemas relacionados con:

  • La claridad de los textos.
  • La coherencia visual.
  • La facilidad de uso.
  • La navegación entre pantallas.
  • La adaptación a dispositivos concretos.
  • Los mensajes de error.
  • Los estados de carga.
  • Los comportamientos inesperados.
  • La experiencia general del usuario.

Una interfaz puede ser técnicamente funcional y, al mismo tiempo, resultar confusa. Por ejemplo, un formulario puede enviar correctamente la información, pero no indicar qué campo contiene un error. Una ventana modal puede abrirse sin problemas, aunque oculte contenido importante o sea difícil de cerrar utilizando el teclado.

Este tipo de situaciones requiere observación e interpretación, dos capacidades que siguen dependiendo en gran medida de la intervención humana.

Pruebas manuales guiadas y pruebas exploratorias

Dentro del QA manual se pueden distinguir dos prácticas principales.

Las pruebas guiadas siguen una secuencia definida previamente. Por ejemplo:

  1. Acceder a la página de registro.
  2. Introducir un correo electrónico válido.
  3. Crear una contraseña.
  4. Aceptar las condiciones.
  5. Enviar el formulario.
  6. Comprobar que aparece la confirmación.
  7. Verificar la recepción del correo de activación.

Este procedimiento permite repetir el caso bajo condiciones similares y comprobar que el resultado se mantiene estable.

El testing exploratorio, en cambio, no se limita a seguir pasos cerrados. La persona aprende sobre la aplicación mientras la utiliza, formula hipótesis y modifica su recorrido en función de lo que observa.

Puede introducir datos no previstos, interrumpir un proceso, volver atrás, abrir varias pestañas o cambiar de tamaño de pantalla para descubrir situaciones que no estaban incluidas en los casos iniciales.

Para profundizar en esta metodología, puedes consultar la guía sobre testing exploratorio y su aplicación práctica.

Por qué la exploración humana continúa siendo necesaria

Una prueba automatizada comprueba aquello para lo que ha sido programada. Si el equipo no ha previsto un determinado escenario, lo más probable es que el script tampoco lo investigue.

Una persona puede observar algo extraño, abandonar el recorrido previsto y dedicar unos minutos a entender qué está ocurriendo. Esa capacidad para adaptar la prueba en tiempo real convierte al QA manual en una herramienta fundamental para descubrir errores inesperados.

Qué es el testing automatizado

El testing automatizado utiliza scripts o herramientas especializadas para ejecutar comprobaciones sin que una persona tenga que repetir manualmente todos los pasos.

Una prueba automatizada realiza una acción, obtiene un resultado y lo compara con una condición esperada. Si ambos valores coinciden, el test se considera correcto. Si no coinciden, comunica un fallo que el equipo debe revisar.

Por ejemplo, una prueba puede comprobar que:

  • Una función calcule correctamente un descuento.
  • Un formulario muestre un mensaje cuando falta un dato obligatorio.
  • Una API devuelva el código de estado esperado.
  • Un usuario pueda iniciar sesión.
  • El carrito conserve los productos añadidos.
  • Una operación no esté disponible para usuarios sin permisos.
  • Una compra genere correctamente un pedido.

La automatización puede aplicarse en diferentes niveles de la aplicación.

Principales tipos de pruebas automatizadas

Tests unitarios

Los tests unitarios comprueban pequeñas unidades de código, como funciones, métodos o clases. Suelen ser rápidos, fáciles de ejecutar y adecuados para validar reglas de negocio.

Por ejemplo, un test unitario puede confirmar que una función encargada de calcular impuestos devuelve el importe correcto para diferentes valores.

Tests de integración

Las pruebas de integración comprueban que varios módulos colaboran correctamente. En lugar de validar una función aislada, analizan la comunicación entre componentes, servicios, bases de datos o APIs.

En proyectos frontend con React, Jest y Testing Library, puede resultar útil revisar estas buenas prácticas para pruebas de integración.

Tests de componentes

Los tests de componentes verifican el comportamiento de elementos de interfaz de forma relativamente aislada.

Pueden comprobar que un botón esté deshabilitado bajo determinadas condiciones, que un formulario muestre un error o que una tarjeta renderice correctamente los datos recibidos.

Si estás trabajando con React, esta introducción a React Testing Library para crear pruebas centradas en el comportamiento del usuario permite ampliar este enfoque.

Tests end-to-end

Los tests end-to-end, también conocidos como E2E, reproducen recorridos completos de usuario. Interactúan con la aplicación de una forma similar a como lo haría una persona.

Un test E2E puede abrir una tienda, seleccionar un producto, añadirlo al carrito, completar los datos de envío y comprobar que se crea el pedido.

Son pruebas valiosas, aunque también suelen ser más lentas y delicadas que los tests unitarios o de integración.

Tests de API

Estas pruebas validan las respuestas de los servicios: códigos de estado, estructuras de datos, permisos, validaciones y tiempos de respuesta.

Normalmente son más rápidas y estables que las pruebas realizadas a través de la interfaz gráfica.

Tests visuales

Los tests de regresión visual comparan capturas de la interfaz para detectar diferencias. Pueden encontrar cambios en tamaños, posiciones, colores, tipografías o espacios.

Sin embargo, una diferencia visual no siempre representa un error. Por esta razón, los resultados suelen necesitar una revisión humana.

Automatizar no significa eliminar el trabajo humano

Aunque los tests se ejecuten automáticamente, la estrategia sigue dependiendo de decisiones humanas.

Alguien debe identificar los riesgos, elegir los escenarios, escribir las pruebas, preparar los datos y analizar los resultados. También es necesario actualizar los tests cuando cambian las reglas de negocio, la interfaz o las integraciones.

La automatización no elimina el trabajo de calidad. Lo desplaza desde la repetición manual hacia el diseño, la programación y el mantenimiento de comprobaciones reutilizables.

QA manual vs testing automatizado: diferencias principales

Ambos enfoques persiguen mejorar la calidad del producto, pero lo hacen de manera diferente.

CriterioQA manualTesting automatizado
Inversión inicialBaja o moderadaModerada o alta
Velocidad en pruebas repetidasBajaAlta
Capacidad exploratoriaMuy altaLimitada
Consistencia entre ejecucionesVariableMuy alta
Evaluación de la experienciaMuy adecuadaParcial
EscalabilidadLimitadaAlta
Integración continuaLimitadaMuy adecuada
Mantenimiento técnicoBajo o moderadoModerado o alto
Detección de situaciones imprevistasAltaDepende de los casos programados
Pruebas de regresiónCostosasMuy eficientes

Velocidad de ejecución

El testing automatizado ofrece una ventaja evidente cuando una misma comprobación debe repetirse muchas veces.

Una suite puede ejecutar cientos de pruebas en pocos minutos e incluso repartirlas entre diferentes procesos. En cambio, una persona debe completar cada recorrido, observar el resultado y documentar cualquier incidencia.

Sin embargo, durante las primeras etapas de una funcionalidad puede ser más rápido realizar una comprobación manual que desarrollar una prueba automatizada.

Inversión inicial

Las pruebas manuales pueden comenzar prácticamente desde el momento en que existe una versión funcional del producto.

La automatización requiere seleccionar herramientas, configurar entornos, preparar datos, escribir código e integrar las pruebas dentro del flujo de desarrollo.

Esta inversión se recupera cuando los casos se ejecutan con frecuencia. Cuantas más repeticiones sean necesarias, mayor será el valor potencial de automatizarlos.

Repetibilidad y consistencia

Un test automatizado ejecuta los mismos pasos y validaciones en cada ocasión. Esto evita variaciones y facilita la comparación de resultados.

Las pruebas manuales pueden variar ligeramente según la persona que las realiza. Sin embargo, esa flexibilidad también permite explorar situaciones nuevas o adaptar la prueba cuando aparece un comportamiento inesperado.

Capacidad de interpretación

La automatización funciona especialmente bien cuando existe una condición concreta y medible: un valor, un estado, una respuesta o la presencia de un elemento.

El QA manual resulta más adecuado cuando hay que evaluar claridad, comodidad, coherencia, jerarquía visual o percepción de confianza.

Mantenimiento

Los casos manuales también necesitan actualizarse, pero modificar un documento suele ser relativamente sencillo.

Los tests automatizados pueden fallar cuando cambia la interfaz, la estructura del código o la información utilizada. Si están demasiado ligados a detalles internos, el equipo puede terminar dedicando más tiempo a reparar pruebas que a detectar errores reales.

Por ello, conviene crear tests centrados en comportamientos relevantes, evitando depender de implementaciones que puedan cambiar con frecuencia.

Cuándo conviene utilizar QA manual

Las pruebas manuales son especialmente valiosas cuando la aplicación requiere interpretación, exploración o una evaluación directa de la experiencia.

Durante las primeras fases de una funcionalidad

Cuando una pantalla cambia constantemente, crear una automatización detallada puede generar demasiado mantenimiento.

En esta etapa suele ser más eficiente comprobar el comportamiento manualmente, ajustar los requisitos y esperar a que el flujo se estabilice antes de automatizarlo.

En sesiones de testing exploratorio

El QA manual permite combinar acciones no previstas y observar cómo responde el sistema.

Por ejemplo, una persona puede:

  • Cambiar rápidamente entre pantallas.
  • Introducir datos extremos.
  • Recargar la página durante una operación.
  • Utilizar varias pestañas.
  • Interrumpir una compra.
  • Cambiar la conexión.
  • Repetir una acción varias veces.
  • Navegar con teclado.

Estas pruebas pueden descubrir problemas que no estaban contemplados inicialmente.

Para evaluar la usabilidad

Una herramienta automática puede comprobar que un elemento existe, pero no necesariamente si su propósito resulta evidente.

La revisión humana es importante para valorar si la navegación es lógica, si los mensajes ayudan a resolver errores o si el producto exige más esfuerzo del necesario.

En revisiones visuales y responsive

Los tests automatizados pueden detectar diferencias, aunque la revisión manual sigue siendo necesaria para valorar la calidad de esas diferencias.

Una persona puede identificar textos cortados, espacios desproporcionados, elementos difíciles de pulsar o contenidos que pierden jerarquía en pantallas pequeñas.

Para comprobaciones puntuales

Si una función se utilizará pocas veces, tiene poco riesgo y no volverá a probarse regularmente, automatizarla puede no compensar.

Una prueba manual documentada puede ser suficiente.

Cuándo conviene utilizar testing automatizado

La automatización suele aportar más valor cuando el comportamiento está bien definido, debe comprobarse con frecuencia o puede provocar consecuencias importantes.

Para las pruebas de regresión

Cada nueva modificación puede afectar a funcionalidades que ya funcionaban correctamente.

Una suite automatizada permite comprobar que los recorridos principales continúan estables después de integrar nuevos cambios.

En una tienda online, por ejemplo, tendría sentido automatizar:

  • El inicio de sesión.
  • La búsqueda de productos.
  • La actualización del carrito.
  • La aplicación de descuentos.
  • El cálculo de gastos de envío.
  • El proceso de pago.
  • La creación del pedido.

Repetir manualmente todos estos escenarios antes de cada publicación sería lento y aumentaría el riesgo de omitir algún paso.

Para integrarlo en CI/CD

Las pruebas automatizadas pueden ejecutarse al crear una solicitud de cambios, integrar código o preparar un despliegue.

De este modo, el equipo recibe información antes de que la modificación llegue a producción. Detectar un error en esta fase suele resultar más sencillo que investigarlo días después.

Para validar múltiples combinaciones de datos

Algunas reglas deben comprobarse con decenas o cientos de valores.

Los descuentos, impuestos, permisos, fechas, límites y conversiones son buenos ejemplos. Automatizar estas combinaciones proporciona una cobertura difícil de conseguir manualmente.

Para proteger errores corregidos

Cuando aparece un defecto importante, conviene crear una prueba que reproduzca ese problema antes de corregirlo.

Después de implementar la solución, el test debe pasar. A partir de ese momento, permanecerá en la suite para evitar que el mismo error vuelva a introducirse.

Para comprobar lógica de negocio y APIs

La lógica interna y las APIs suelen ser más estables que la interfaz. Por ello, los tests unitarios, de integración y de servicios acostumbran a ofrecer una buena relación entre coste, velocidad y cobertura.

Qué pruebas deberían automatizarse primero

No es necesario automatizar todas las pruebas. De hecho, intentar hacerlo puede producir una suite lenta y difícil de mantener.

La prioridad debería centrarse en:

  1. Los recorridos críticos para el negocio.
  2. Las funcionalidades que se comprueban en cada entrega.
  3. Las reglas estables.
  4. Los escenarios con muchas combinaciones de datos.
  5. Los errores graves que ya se han producido.
  6. Las acciones cuyo fallo afectaría a muchos usuarios.
  7. Las comprobaciones necesarias antes de publicar.

Por ejemplo, en una aplicación de reservas podría ser prioritario automatizar la disponibilidad, el cálculo del precio, la creación de la reserva y la cancelación.

En cambio, una revisión sobre la claridad del calendario o la facilidad para modificar una fecha continuaría necesitando intervención humana.

Qué no conviene automatizar

No suele ser rentable automatizar:

  • Prototipos que se descartarán pronto.
  • Funcionalidades que cambian cada pocos días.
  • Pruebas que solo se ejecutarán una vez.
  • Comprobaciones puramente subjetivas.
  • Escenarios de bajo impacto y poca frecuencia.
  • Detalles internos sin relevancia para el usuario.
  • Flujos que no pueden prepararse de forma estable.

Una prueba automatizada debería cumplir tres condiciones: detectar un riesgo importante, ejecutarse con suficiente frecuencia y tener un mantenimiento razonable.

Cómo combinar QA manual y testing automatizado

La estrategia más efectiva consiste en utilizar cada enfoque donde aporta mejores resultados.

Los tests unitarios pueden proteger las reglas de negocio. Los tests de integración pueden validar la comunicación entre módulos. Los tests E2E pueden cubrir los recorridos esenciales. Finalmente, las pruebas manuales pueden centrarse en exploración, usabilidad y revisión visual.

Ejemplo de una estrategia híbrida

Imaginemos una aplicación para reservar alojamientos.

El equipo podría automatizar:

  • El cálculo del precio total.
  • La consulta de disponibilidad.
  • La autenticación.
  • La creación de reservas.
  • La cancelación.
  • Los permisos de usuario.
  • Las respuestas de la API.
  • El recorrido principal de pago.

Las pruebas manuales podrían centrarse en:

  • La claridad del buscador.
  • La facilidad para seleccionar fechas.
  • La comprensión de los filtros.
  • Los mensajes mostrados cuando no hay disponibilidad.
  • El uso desde dispositivos reales.
  • La experiencia al modificar una reserva.
  • La legibilidad de la información.

Esta combinación reduce el tiempo dedicado a tareas repetitivas sin perder la capacidad de detectar problemas difíciles de anticipar.

La pirámide de testing como referencia

Una estrategia habitual utiliza muchos tests rápidos en las capas inferiores y menos pruebas completas en las superiores.

La distribución podría incluir:

  • Numerosos tests unitarios.
  • Una cantidad moderada de tests de integración.
  • Un conjunto reducido de tests end-to-end.
  • Sesiones manuales y exploratorias en momentos estratégicos.

No debe interpretarse como una fórmula rígida. Cada producto tiene riesgos diferentes y necesita su propia estrategia.

Una aplicación financiera, una tienda online, un gestor de contenidos y una herramienta interna no requieren exactamente la misma cobertura.

Además, la calidad no depende únicamente del equipo de QA. Diseñadores, desarrolladores, responsables de producto y otros stakeholders implicados en el desarrollo de software participan en la definición de requisitos y en la prevención de errores.

Cómo decidir entre una prueba manual y una automatizada

Antes de automatizar un caso, conviene responder a las siguientes preguntas.

¿Con qué frecuencia se ejecutará?

Si la prueba debe repetirse en cada entrega, probablemente será una buena candidata para la automatización.

Si únicamente se realizará una vez, una comprobación manual puede ser suficiente.

¿El comportamiento está estabilizado?

Automatizar una funcionalidad que cambia constantemente puede producir tests frágiles y costosos.

Puede ser preferible esperar o automatizar solo las capas que ya tengan reglas estables.

¿Qué impacto tendría un error?

Los procesos relacionados con pagos, permisos, datos personales, seguridad o información crítica necesitan una cobertura más sólida.

Cuanto mayor sea el impacto potencial, más importante será incorporar comprobaciones repetibles.

¿La prueba requiere criterio humano?

Cuando hay que evaluar claridad, facilidad de uso, diseño o percepción, la prueba manual suele ser más adecuada.

¿Cuánto costará mantenerla?

El coste de una automatización no termina después de escribir el test. También deben considerarse los datos, entornos, dependencias, actualizaciones y falsos fallos.

Criterio práctico de priorización

Una forma sencilla de valorar cada caso es combinar tres factores:

Prioridad de automatización = frecuencia de ejecución × impacto del fallo × estabilidad del comportamiento

Una comprobación frecuente, crítica y estable será una buena candidata para automatizar.

Una prueba poco frecuente, de bajo impacto y asociada a una funcionalidad cambiante debería continuar siendo manual.

Errores frecuentes en una estrategia de testing

Uno de los errores más habituales es intentar automatizar toda la aplicación desde el inicio. Esta decisión puede producir una suite difícil de mantener antes de que el producto esté suficientemente estabilizado.

Otro problema consiste en medir la calidad por el número de tests. Tener cientos de pruebas no garantiza una cobertura útil si todas comprueban detalles poco relevantes.

También es frecuente depender demasiado de los tests end-to-end. Aunque permiten validar recorridos completos, suelen ser más lentos y frágiles. La lógica debería protegerse principalmente mediante tests unitarios y de integración.

Por último, no conviene considerar el QA manual como una actividad provisional que desaparecerá cuando aumente la automatización.

La exploración humana cumple una función diferente: investiga, interpreta y descubre riesgos que los casos programados todavía no contemplan.

Preguntas frecuentes sobre QA manual y testing automatizado

¿El testing automatizado puede sustituir completamente al QA manual?

No. La automatización puede encargarse de muchas comprobaciones repetitivas, pero no sustituye la capacidad humana para explorar, interpretar y evaluar la experiencia.

Los mejores resultados aparecen cuando ambos enfoques se complementan.

¿Cuándo debería empezar un proyecto a automatizar pruebas?

Puede comenzar desde las primeras etapas con la lógica estable y crítica, especialmente mediante tests unitarios y de integración.

Las pruebas de interfaz deberían incorporarse progresivamente cuando los recorridos estén suficientemente definidos.

¿Es más caro el QA manual o el testing automatizado?

Depende de la frecuencia y del plazo analizado.

Las pruebas manuales suelen requerir una inversión inicial menor, pero resultan costosas cuando deben repetirse continuamente. La automatización necesita más preparación, aunque puede reducir el coste de las regresiones a medio y largo plazo.

Automatizar lo previsible y explorar lo inesperado

La comparación entre QA manual y testing automatizado no debería plantearse como una competición.

Las pruebas manuales aportan curiosidad, interpretación y conocimiento del contexto. Las pruebas automatizadas proporcionan velocidad, consistencia y capacidad para comprobar el producto después de cada cambio.

Un equipo maduro no se pregunta únicamente qué puede automatizar, sino qué merece la pena automatizar. Tampoco reserva la revisión manual para los últimos minutos antes de publicar.

La estrategia debe adaptarse a los riesgos reales, a la estabilidad del producto y a los recursos disponibles. Automatizar demasiado pronto puede aumentar el mantenimiento. Depender exclusivamente de comprobaciones manuales puede ralentizar las entregas y facilitar que reaparezcan errores conocidos.

En definitiva, el testing automatizado permite proteger los comportamientos previsibles, mientras que el QA manual ayuda a descubrir aquello que todavía no se había imaginado. La combinación de ambos enfoques permite desarrollar productos más fiables, comprensibles y preparados para evolucionar.

Scroll-driven animations: qué son y cómo usarlas

Posted on by marta

Las scroll-driven animations son una de las novedades más interesantes de CSS moderno porque permiten crear animaciones vinculadas directamente al desplazamiento del usuario. En lugar de depender únicamente del tiempo, como ocurre con una animación tradicional, este tipo de animación avanza según el scroll de la página o según la posición de un elemento dentro del viewport.

Dicho de otra forma: ya no necesitamos pensar siempre en animaciones que duran “un segundo” o “medio segundo”. Ahora podemos crear efectos que progresan a medida que la persona navega por el contenido. Esto abre la puerta a barras de progreso de lectura, tarjetas que aparecen al entrar en pantalla, imágenes que se transforman durante el recorrido o secciones narrativas que acompañan visualmente al usuario.

Si ya has trabajado con animaciones CSS, probablemente estés familiarizada con @keyframes, animation, transition, opacity o transform. Las scroll-driven animations parten de esa misma base, pero introducen una diferencia importante: la línea de tiempo de la animación deja de estar controlada por segundos y pasa a estar controlada por el scroll.

En este artículo vamos a ver qué son las animaciones con scroll CSS, cómo funcionan, qué papel tienen animation-timeline, scroll() y view(), cuándo conviene usarlas y qué buenas prácticas deberías aplicar para que el resultado sea fluido, accesible y útil.

Qué son las scroll-driven animations en CSS

Las scroll-driven animations son animaciones cuyo progreso depende del desplazamiento del usuario. En una animación CSS tradicional, el navegador reproduce una secuencia durante un tiempo concreto. Por ejemplo, puedes hacer que una tarjeta pase de opacity: 0 a opacity: 1 durante 0.4s.

.card {
  opacity: 0;
  transform: translateY(24px);
  animation: aparecer 0.4s ease forwards;
}

@keyframes aparecer {
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

En este caso, la animación empieza, dura un tiempo determinado y termina. El usuario no controla su progreso. Puede activarse al cargar la página, al añadir una clase o al interactuar con un elemento, pero la animación en sí avanza por tiempo.

Con una scroll animation CSS, la lógica cambia. El progreso de la animación se vincula al scroll. Si el usuario baja por la página, la animación avanza. Si se detiene, la animación se detiene. Si vuelve hacia arriba, la animación puede retroceder.

Esta relación directa entre movimiento y desplazamiento permite crear experiencias más conectadas con el ritmo real de navegación.

La diferencia clave está en la línea de tiempo

Toda animación necesita una línea de tiempo. En CSS clásico, esa línea de tiempo suele estar basada en segundos. Con las scroll-driven animations, esa línea de tiempo puede depender del desplazamiento de la página o de la visibilidad de un elemento.

Por eso, cuando hablamos de CSS scroll timeline, hablamos de una forma distinta de calcular el progreso de una animación. Ya no preguntamos “cuánto tiempo ha pasado”, sino “cuánto ha avanzado el usuario en el scroll” o “qué parte del elemento está visible”.

Esto es especialmente útil en páginas largas, artículos técnicos, landings, portfolios, documentación o experiencias de storytelling visual.

Conceptos básicos: animation-timeline, scroll() y view()

Para usar scroll-driven animations en CSS, hay tres conceptos que conviene tener claros: animation-timeline, scroll() y view().

animation-timeline

La propiedad animation-timeline permite indicar qué línea de tiempo controla una animación. Por defecto, una animación CSS usa una línea de tiempo basada en el tiempo del documento. Pero con esta propiedad podemos asociarla a una línea de tiempo basada en scroll.

.elemento {
  animation: revelar linear both;
  animation-timeline: scroll();
}

En este ejemplo, la animación revelar no avanza por duración temporal, sino por el progreso del scroll.

Un detalle importante: si usas la propiedad abreviada animation, conviene declarar animation-timeline después. Así evitas que el shorthand sobrescriba valores relacionados con la animación.

.elemento {
  animation: revelar linear both;
  animation-timeline: view();
}

Si quieres profundizar en cómo funcionan las animaciones tradicionales antes de pasar a este nivel, puede ayudarte repasar la diferencia entre transition y animation en CSS, porque entender esa base facilita mucho el uso de timelines más avanzadas.

scroll(): animar según el progreso del scroll

La función scroll() vincula la animación al desplazamiento de un contenedor. Puede ser el scroll principal de la página o el de un contenedor concreto.

Uno de los ejemplos más claros es una barra de progreso de lectura.

<div class="reading-progress"></div>

.reading-progress {
  position: fixed;
  top: 0;
  left: 0;
  z-index: 1000;
  width: 100%;
  height: 4px;
  transform: scaleX(0);
  transform-origin: left;
  background: currentColor;
  animation: grow-progress linear both;
  animation-timeline: scroll(root block);
}

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

Este patrón es muy útil en artículos extensos porque permite mostrar visualmente cuánto contenido se ha recorrido. Además, no requiere JavaScript para calcular el porcentaje de scroll.

El valor scroll(root block) indica que la animación se basa en el scroll principal del documento, en el eje de bloque, que normalmente coincide con el desplazamiento vertical.

view(): animar según la visibilidad del elemento

La función view() sirve para crear animaciones basadas en la entrada y salida de un elemento dentro del viewport o de un contenedor de scroll.

Por ejemplo, podemos hacer que una tarjeta aparezca suavemente al entrar en pantalla:

.card {
  opacity: 0;
  transform: translateY(32px);
  animation: reveal-card linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 35%;
}

@keyframes reveal-card {
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Aquí, cada tarjeta se anima según su propia relación con el área visible. La animación empieza cuando el elemento entra en pantalla y termina cuando cubre una parte determinada del viewport.

La propiedad animation-range permite ajustar ese tramo. Esto es importante porque no siempre queremos que una animación empiece en el primer píxel visible del elemento. A veces resulta más natural que empiece un poco después y termine antes de que el elemento esté completamente centrado.

Diferencia entre animaciones activadas por scroll y animaciones controladas por scroll

Es habitual confundir las animaciones activadas por scroll con las animaciones controladas por scroll, pero no son exactamente lo mismo.

Una animación activada por scroll suele funcionar así: el usuario llega a una sección, JavaScript detecta que el elemento entra en pantalla y se añade una clase. A partir de ahí, la animación se reproduce durante un tiempo concreto.

.card {
  opacity: 0;
  transform: translateY(24px);
  transition: opacity 0.4s ease, transform 0.4s ease;
}

.card.visible {
  opacity: 1;
  transform: translateY(0);
}

En este caso, el scroll activa la animación, pero no controla su progreso. Una vez activada, la transición depende del tiempo.

En cambio, en una scroll-driven animation, el scroll no solo dispara el efecto: lo dirige. La animación avanza, se pausa o retrocede según el desplazamiento del usuario.

Esta diferencia es importante porque hace que la experiencia se sienta más fluida y más conectada con la navegación.

Ejemplo práctico: barra de progreso de lectura

Una barra de progreso es uno de los mejores ejemplos para empezar porque tiene una función clara. No es una animación decorativa, sino una ayuda visual para saber cuánto queda de lectura.

<div class="reading-progress"></div>

<article class="post">
  <h1>Scroll-driven animations: qué son y cómo usarlas</h1>
  <p>Contenido del artículo...</p>
</article>

.reading-progress {
  position: fixed;
  top: 0;
  left: 0;
  z-index: 1000;
  width: 100%;
  height: 4px;
  transform: scaleX(0);
  transform-origin: left;
  animation: reading-progress linear both;
  animation-timeline: scroll(root block);
}

@keyframes reading-progress {
  to {
    transform: scaleX(1);
  }
}

Este ejemplo funciona bien porque utiliza transform: scaleX(), una propiedad adecuada para animaciones fluidas. En general, siempre que puedas, es preferible animar transform y opacity antes que propiedades que afecten al layout. Si quieres ampliar esta idea, puedes leer el artículo sobre por qué animar transform y opacity antes que width o height.

Ejemplo práctico: revelar tarjetas al entrar en pantalla

Otro uso muy común de las animaciones con scroll CSS es revelar tarjetas, imágenes o bloques de contenido a medida que aparecen en pantalla.

<section class="grid">
  <article class="card">
    <h2>Proyecto destacado</h2>
    <p>Descripción breve del proyecto.</p>
  </article>

  <article class="card">
    <h2>Otro proyecto</h2>
    <p>Descripción breve del proyecto.</p>
  </article>
</section>

.card {
  opacity: 0;
  transform: translateY(32px);
  animation: reveal-card linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 35%;
}

@keyframes reveal-card {
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Este patrón puede funcionar muy bien en portfolios, páginas de servicios, casos de estudio o landings. La clave está en que el efecto sea suave y no interrumpa la lectura.

Si cada elemento aparece con un desplazamiento exagerado, el resultado puede parecer artificial. En cambio, un movimiento breve y sutil puede ayudar a guiar la mirada sin robar protagonismo al contenido.

Cómo ajustar animation-range

La propiedad animation-range permite definir en qué tramo de la línea de tiempo se ejecuta la animación.

animation-range: entry 10% cover 40%;

Este ajuste hace que la animación empiece cuando el elemento ya ha entrado ligeramente en pantalla y termine cuando cubre una parte concreta del viewport.

No existe un único valor correcto. Depende del diseño, del tamaño del elemento, del ritmo de la página y del tipo de experiencia que quieras crear. Por eso conviene probar varios rangos hasta que el movimiento se sienta natural.

Ejemplo práctico: imagen con efecto de escala durante el scroll

Las scroll-driven animations también pueden utilizarse en composiciones más visuales. Por ejemplo, una imagen que aumenta ligeramente de tamaño mientras el usuario recorre una sección.

<section class="hero-scroll">
  <img src="imagen.jpg" alt="Detalle visual del proyecto" class="hero-image">
</section>

.hero-scroll {
  min-height: 150vh;
}

.hero-image {
  position: sticky;
  top: 20vh;
  width: 100%;
  transform: scale(0.9);
  animation: zoom-image linear both;
  animation-timeline: view();
  animation-range: entry 0% exit 100%;
}

@keyframes zoom-image {
  to {
    transform: scale(1.05);
  }
}

Este tipo de efecto puede aportar profundidad en una página editorial o en una sección visual de portfolio. Sin embargo, conviene usarlo con moderación. Un pequeño cambio de escala puede ser elegante; un zoom excesivo puede resultar molesto.

Buenas prácticas para usar scroll-driven animations

Las scroll-driven animations son potentes, pero no deberían aplicarse sin criterio. Como ocurre con cualquier recurso visual, la pregunta principal no es “¿puedo animarlo?”, sino “¿esta animación mejora la experiencia?”.

Usa la animación con una intención clara

Una animación debería aportar orientación, continuidad, feedback o jerarquía visual. Una barra de progreso comunica avance. Una tarjeta que aparece suavemente puede dirigir la atención hacia un bloque importante. Un efecto de escala puede reforzar una narrativa visual.

Pero si la animación no ayuda al usuario a entender mejor la interfaz, quizá sea prescindible. En diseño web, menos movimiento suele ser mejor que demasiado movimiento.

Para decidir cuándo tiene sentido animar y cuándo es mejor evitarlo, te puede interesar revisar esta guía sobre cuándo usar animaciones CSS y cuándo evitarlas.

Prioriza propiedades eficientes

Siempre que sea posible, anima transform y opacity. Estas propiedades suelen ofrecer mejor rendimiento porque no obligan al navegador a recalcular la estructura completa de la página en cada paso de la animación.

Por ejemplo, para una barra de progreso, es mejor utilizar transform: scaleX() que modificar directamente el ancho con width.

/* Mejor opción */
transform: scaleX(1);

/* Menos recomendable en muchos casos */
width: 100%;

Esto no significa que nunca puedas animar otras propiedades, pero sí que deberías hacerlo con cuidado. Si estás trabajando en interfaces complejas, puede ayudarte este artículo sobre animaciones CSS y rendimiento.

Respeta prefers-reduced-motion

La accesibilidad es fundamental. Algunas personas prefieren reducir el movimiento en sus dispositivos porque ciertas animaciones pueden provocar incomodidad, mareo o dificultad para concentrarse.

Puedes ofrecer una alternativa con prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {
  .card,
  .hero-image,
  .reading-progress {
    animation: none;
    transform: none;
    opacity: 1;
  }
}

Este bloque desactiva las animaciones para quienes han configurado esa preferencia en el sistema o en el navegador.

Si quieres profundizar en esta parte, puedes leer la guía sobre prefers-reduced-motion en CSS, especialmente útil cuando trabajas con animaciones en interfaces reales.

Diseña primero una versión sin animación

Una buena experiencia no debería depender por completo de la animación. El contenido debe poder leerse y entenderse aunque el navegador no soporte esta funcionalidad o aunque el usuario haya reducido el movimiento.

Por eso, lo recomendable es trabajar con mejora progresiva. Primero diseña una versión estática, clara y funcional. Después añade las scroll-driven animations como una capa de enriquecimiento visual.

Puedes usar @supports para aplicar estos estilos solo en navegadores compatibles:

@supports (animation-timeline: scroll()) {
  .reading-progress {
    animation: reading-progress linear both;
    animation-timeline: scroll(root block);
  }
}

Esta estrategia ayuda a evitar errores y mantiene una experiencia sólida para más usuarios.

Errores comunes al usar animaciones con scroll CSS

Animar demasiados elementos

Uno de los errores más frecuentes es querer animarlo todo. Si cada bloque aparece, se desplaza, escala o cambia de color, la página puede volverse pesada y difícil de leer.

La animación necesita ritmo. Debe aparecer en momentos concretos y con un propósito claro. Si todo se mueve, nada destaca.

No ajustar bien el rango de animación

Otro error habitual es no controlar cuándo empieza y termina el efecto. Si la animación empieza demasiado tarde, puede pasar desapercibida. Si termina demasiado rápido, puede resultar brusca.

animation-range es una herramienta clave para ajustar ese comportamiento. No la trates como un detalle menor: muchas veces, la diferencia entre una animación elegante y una incómoda está precisamente en ese ajuste.

Confundir espectacularidad con buena experiencia

Una animación llamativa puede impresionar durante unos segundos, pero eso no significa que mejore la UX. En una web profesional, las mejores animaciones suelen ser las que acompañan sin interrumpir.

El objetivo no es que el usuario piense “qué animación tan bonita”, sino que la navegación resulte más clara, fluida y comprensible.

Cuándo usar scroll-driven animations

Las scroll-driven animations son especialmente útiles en:

  • Artículos largos con barra de progreso.
  • Landings con secciones diferenciadas.
  • Portfolios visuales.
  • Páginas de producto con storytelling.
  • Casos de estudio.
  • Documentación técnica.
  • Bloques que necesitan aparecer de forma progresiva.
  • Imágenes o elementos destacados que acompañan el recorrido.

También pueden combinarse con otros recursos de animación CSS, como @keyframes, transiciones suaves y microinteracciones. Si quieres reforzar esa base, puedes consultar la guía sobre @keyframes en CSS.

Cuándo evitarlas

Conviene evitarlas cuando la animación pueda entorpecer la tarea principal. Por ejemplo, en formularios largos, procesos de compra, paneles de gestión o interfaces donde la prioridad sea completar una acción de forma rápida y sin distracciones.

También deberías tener cuidado en páginas visualmente densas. Si ya hay mucho contenido, muchos colores o muchos elementos compitiendo por la atención, añadir movimiento puede aumentar la carga cognitiva.

En estos casos, una experiencia más estática, clara y directa puede ser mucho más eficaz.

FAQs sobre scroll-driven animations

¿Las scroll-driven animations sustituyen a JavaScript?

No siempre. Las scroll-driven animations permiten resolver muchos efectos visuales sin JavaScript, especialmente cuando el objetivo es vincular una animación al progreso del scroll o a la visibilidad de un elemento. Sin embargo, JavaScript sigue siendo necesario para lógica compleja, cambios de estado avanzados, sincronización con datos o interacciones que van más allá de la presentación visual.

¿Puedo usar scroll-driven animations en producción?

Sí, pero con criterio. Lo ideal es usarlas como mejora progresiva, comprobar compatibilidad, respetar prefers-reduced-motion y evitar que una funcionalidad esencial dependa únicamente de ellas. Para barras de progreso, revelados suaves o efectos visuales complementarios, pueden ser una opción muy interesante.

¿Qué diferencia hay entre scroll() y view()?

scroll() vincula la animación al progreso de desplazamiento de un contenedor, como la página completa. Es ideal para barras de progreso o efectos asociados al avance general del scroll. view() vincula la animación a la visibilidad de un elemento dentro del viewport, por lo que resulta muy útil para revelar tarjetas, imágenes o secciones cuando entran en pantalla.

Animar con scroll también es diseñar la experiencia

Las scroll-driven animations representan un paso muy interesante en la evolución de CSS. Nos permiten crear animaciones más conectadas con el comportamiento real del usuario y reducir la dependencia de JavaScript en muchos efectos visuales habituales.

Pero su valor no está en hacer páginas más espectaculares, sino en hacerlas más claras. Una animación vinculada al scroll puede orientar, acompañar la lectura, reforzar una jerarquía visual o convertir una sección larga en una experiencia más fluida. Sin embargo, también puede convertirse en una distracción si se usa sin medida.

La clave está en empezar por casos sencillos: una barra de progreso, una tarjeta que aparece suavemente, una imagen que acompaña el recorrido de una sección. Después, observa si la animación realmente aporta algo. Si ayuda a entender mejor el contenido, tiene sentido. Si solo llama la atención, quizá sea mejor simplificar.

Porque animar bien no significa mover muchas cosas. Significa mover lo justo, en el momento adecuado y con una intención clara.