Movimiento con Intención: Animación que No Arruina el Rendimiento
El movimiento es la forma más rápida de que una web parezca cara. También es la forma más rápida de que parezca rota, y la distancia entre esos dos resultados es más corta de lo que la gente espera.
La diferencia no es el gusto, ni el presupuesto, ni qué librería elegiste. Es si el movimiento se planificó con el desarrollo o se atornilló cerca del final. La animación añadida tarde pelea contra la maqueta a la que la añadiste. Pierde fotogramas en los móviles que usan tus clientes reales, y suele llegar en el mismo sprint que la fecha de lanzamiento, que es justo cuando nadie tiene tiempo de probarla en nada.
Anima las propiedades baratas, evita las caras
Este es el único conocimiento técnico que hace la mayor parte del trabajo, y no es complicado. El navegador resuelve algunos cambios casi gratis y otros a un coste real.
Transform y opacity son el par barato. El compositor puede encargarse de ellos por su cuenta, sin pedirle nada al resto del pipeline de renderizado, y por eso una animación basada en transform aguanta 60fps en hardware donde la alternativa se atraganta. Todo lo demás es donde está el problema. Anima width, height, top, left, margin o padding y obligas al navegador a recalcular la maqueta en cada fotograma, para ese elemento y a menudo para buena parte de la página que lo rodea.
Así que: mueve las cosas con translate, escálalas con scale, fúndelas con opacity. Si te encuentras animando una propiedad de maquetación, el arreglo habitual es tirar de transform, y el segundo arreglo más habitual es aceptar que el efecto no vale lo que cuesta.
Un matiz que pilla a mucha gente, porque el consejo se repite sin él: will-change no es un ajuste de rendimiento que espolvoreas por encima. Cada uno promociona un elemento a su propia capa, y las capas cuestan memoria. Ponlo en cuarenta elementos y dejarás la página más lenta de lo que estaba antes de optimizarla.
La buena noticia es que nada de esto hay que creérselo por fe, y este es el hábito que merece la pena construir. Las DevTools de Chrome te enseñan las capas que ha creado la página y te iluminan las zonas que se están repintando mientras haces scroll. Si un scroll está provocando que se repinten áreas grandes, acabas de encontrar el problema, y normalmente lo encuentras en unos treinta segundos. Activa de paso el medidor de fotogramas. Ver caer el número en una interacción concreta es mucho más útil que una puntuación de Lighthouse a posteriori, porque te dice qué interacción, y no que algo, en algún sitio, va lento.
Trata el scroll como una sola línea de tiempo, no como cuarenta listeners
El scroll es la interacción principal en casi cualquier web de marketing, así que merece la pena ser deliberado. El patrón que sale mal es un montón de listeners de scroll independientes, cada uno añadido por quien construyó esa sección, todos disparándose en el mismo fotograma y todos midiendo el DOM en momentos ligeramente distintos.
El síntoma son tirones que solo aparecen cuando dos efectos se solapan, lo que los hace miserables de reproducir y facilísimos de publicar. Nosotros usamos un único bucle. Las secciones fijadas, las revelaciones ligadas al scroll y los efectos que reaccionan a la velocidad leen todos de una sola fuente de verdad, así que nada mide la maqueta mientras otra cosa la está cambiando.
- Un solo bucle de requestAnimationFrame para scroll y animación, no uno por componente.
- Lee la maqueta en bloque y escribe en bloque. Intercalar ambas cosas es lo que provoca los reflows forzados.
- Usa IntersectionObserver para saber qué está en pantalla. No lo calcules tú desde la posición del scroll.
- Carga en diferido todo lo pesado —WebGL sobre todo— por debajo del pliegue, y asegúrate de que la página está completa sin ello.
Si la animación no sobrevive a un Android de hace tres años con el wifi de un hotel, no está terminada. Es una demo.
El movimiento reducido es un estado diseñado, no un plan B
Cada animación que publicamos tiene su rama de prefers-reduced-motion, y la diseñamos en vez de generarla. Existe la versión perezosa en la que desactivas todas las transiciones y lo llamas accesibilidad, y normalmente produce una página que da saltos raros porque media maqueta daba por hecho que algo iba a entrar animado.
Hacerlo bien es mejor para quien lo necesita, evidentemente. Pero además es una herramienta de diagnóstico muy útil para el equipo, y esta es la parte que conviene interiorizar: si la página deja de tener sentido cuando quitas el movimiento, el contenido de debajo era demasiado flojo. La animación estaba haciendo el trabajo que debería estar haciendo el texto. Eso es un problema de contenido disfrazado de ingeniería, y es mejor encontrarlo en la semana tres que después del lanzamiento.
El movimiento pertenece al design system
Aquí es donde esto se tuerce a escala, y en realidad no es un problema de rendimiento en absoluto. Las duraciones y las curvas de aceleración se eligen por componente, por quien construyó ese componente, el día que lo construyó. Nadie las anota. Seis meses después la web tiene catorce curvas distintas y cuatro ideas sobre cuánto debe durar una transición, y se siente sutilmente incoherente de una forma difícil de nombrar en una revisión.
El movimiento debería tokenizarse exactamente igual que el color y el espaciado. Un conjunto pequeño de duraciones. Un conjunto más pequeño de curvas. Nombradas por su función, para que la gente elija la correcta sin necesidad de tener una opinión sobre valores de cubic-bezier.
- 01Con tres duraciones suele bastar. Algo rápido para los cambios de estado de aquello que estás tocando, algo medio para elementos que entran y salen, algo más lento para transiciones grandes y deliberadas. Rápida, media, lenta; y si necesitas una cuarta, pregúntate antes por qué.
- 02Dos o tres curvas de aceleración como mucho. Una que arranque rápido y se asiente para lo que llega, una simétrica para lo que se mueve bajo manipulación directa. Casi todas las webs necesitan menos de las que tienen.
- 03Deja por escrito cuándo no animar. Tablas de datos, errores de validación de formularios, cualquier cosa que aparezca porque algo ha ido mal. El movimiento en un mensaje de error se lee como decoración justo en el momento en que alguien quiere información.
Buena parte de lo que se le está pagando a una agencia de design system es esto, y es lo primero que suele caerse del alcance porque es invisible en una presentación. También es lo que determina si el sistema seguirá aguantando dentro de un año, cuando quienes lo construyeron ya estén en otra cosa.
Fija un presupuesto de rendimiento, y fíjalo pronto
Fijamos objetivos de Lighthouse y Core Web Vitals al principio de un desarrollo y los tratamos como criterios de aceptación, igual que cualquier requisito funcional. Importa que ocurra al principio. Un presupuesto acordado en la semana uno es una restricción de diseño que moldea lo que se construye; ese mismo presupuesto introducido en la semana diez son solo malas noticias, y para entonces las decisiones caras ya están sosteniendo el edificio.
Dos de las tres Core Web Vitals están directamente expuestas al movimiento, cosa que conviene saber antes de empezar. Cumulative Layout Shift castiga justo las animaciones que mueven la maqueta, así que la regla de quedarse en el compositor se paga dos veces. E Interaction to Next Paint, que sustituyó a First Input Delay en 2024, mide con qué rapidez responde la página cuando alguien hace algo de verdad: un hilo principal ocupado ejecutando tu animación de portada es un hilo principal que no está respondiendo a un toque.
La versión práctica: mide en un móvil Android corriente con la CPU limitada, no en la máquina en la que lo construiste. Todas las animaciones se ven bien en el portátil de un desarrollador. Eso no es una prueba útil y nunca lo ha sido.
Qué te compra todo esto
Webs que se sienten vivas y siguen cargando rápido, que la gente plantea como un dilema y en su mayor parte no lo es. Los dos objetivos solo entran en conflicto cuando el movimiento llega tarde y compite por unos recursos que ya estaban comprometidos. Planifícalo desde el primer commit y no hay nada que ceder, porque el presupuesto formaba parte del diseño en lugar de ser algo en lo que había que encajar la animación después.
El movimiento, además, hace trabajo comercial cuando está bien hecho, no solo estético. Muestra cambios de estado para que la gente sepa que ha pasado algo. Dirige la atención a la única cosa de la página que importa. Cubre la carga con elegancia en lugar de dejar un rectángulo en blanco. Hay más sobre cómo se conecta eso con las solicitudes de contacto en diseño web orientado a conversión, que recorre el mismo terreno desde el otro extremo.
Si estás construyendo o reparando un sistema en el que esto tiene que ser consistente en muchas superficies, ese es el trabajo que hacemos. Y el único hábito que merece la pena adoptar hoy: elige tus tres duraciones antes de construir el primer componente, no después de haber construido cuarenta.
