wandres.dev
LOTTIE Y AFTER EFFECTS · La animación del diseñador

Las alternativas y cuándo Lottie es la decisión correcta

SVG animado, vídeo con canal alfa, hojas de sprites, Rive y rehacerlo en código: qué cuesta cada opción, con los comandos reales, y el criterio para elegir.

⏱ 20 min

Casi todas las decisiones de usar Lottie se toman por descarte implícito: el diseñador entrega un fichero de After Effects y la pregunta nunca llega a formularse. Merece formularse, porque hay cuatro alternativas con perfiles de coste muy distintos y en bastantes casos ganan con claridad. Y hay un caso en el que Lottie no tiene rival, que conviene reconocer para no pelearse con él.

🎯 Al terminar esta lección sabrás
  • Comparar SVG animado, vídeo con alfa, hoja de sprites, Rive y código con criterios de coste.
  • Producir un vídeo con canal alfa que funcione en los cuatro motores.
  • Situar Rive frente a Lottie en términos de modelo, no de marca.
  • Aplicar un criterio de decisión que no dependa de qué herramienta usó quien diseñó.

El cuadro de opciones

Opción Coste de arranque Coste por fotograma Escala sin perder Recolorea Interactúa
CSS o SVG animado a mano Nulo Casi nulo si va al compositor
Hoja de sprites con steps() Una imagen Casi nulo No No Play y pause
Vídeo con canal alfa Decodificador Fuera del hilo principal Hasta su resolución No Play, pause y buscar
Lottie Parseo más motor Alto y continuo Con temas Play, pause y segmentos
Rive Motor WASM Medio Máquina de estados

Las tres primeras filas comparten una propiedad que Lottie no tiene: el trabajo por fotograma no lo hace tu JavaScript. Una animación CSS de transform la ejecuta el compositor, una hoja de sprites es un cambio de background-position que el compositor también resuelve, y un vídeo lo decodifica un proceso aparte con aceleración por hardware. Ninguna de las tres compite con tu interfaz por el hilo principal. Esa diferencia estructural pesa más que cualquier comparación de kilobytes.

SVG animado a mano. Exporta el SVG estático desde la herramienta de diseño, límpialo y anímalo con CSS. Cubre perfectamente lo que la mayoría de los Lottie hacen en la práctica: un icono que se transforma, un trazo que se dibuja, un elemento que entra. Si la pieza tiene menos de una docena de formas, esto es casi siempre lo correcto y además es lo único que puedes ajustar sin volver a pedirle nada a nadie.

Hoja de sprites. Renderiza la animación a una tira de fotogramas y muévela con steps(). Es la técnica más vieja del oficio y sigue siendo imbatible para bucles cortos con formas complicadas: el coste por fotograma es exactamente el de mover un fondo, sea la ilustración lo compleja que sea.

.explosion {
  width: 128px;
  height: 128px;
  background: url("/sprites/explosion.png") 0 0 / 3200px 128px no-repeat;
  animation: correr 1s steps(25) infinite;
}

@keyframes correr {
  to { background-position: -3200px 0; }
}

@media (prefers-reduced-motion: reduce) {
  .explosion { animation: none; background-position: -1600px 0; }
}

El precio es el peso de la imagen y que no escala: veinticinco fotogramas de 128 píxeles a densidad 2 son una imagen de 6400 píxeles de ancho. Para bucles de menos de dos segundos en tamaños pequeños, sale a cuenta con frecuencia.

Vídeo con canal alfa

Es la opción más infravalorada y la que mejor resuelve el caso difícil: una ilustración compleja, con degradados, desenfoques y efectos que Lottie no soporta, sobre un fondo que no es plano. El decodificador de vídeo es hardware dedicado; la animación puede tener diez mil elementos y el coste por fotograma es el mismo.

El problema histórico era el soporte, y sigue exigiendo servir dos ficheros porque los motores no coinciden en el códec con alfa. VP9 dentro de WebM cubre Chromium y Firefox; HEVC con alfa cubre Safari.

# WebM con VP9 y canal alfa, para Chromium y Firefox
ffmpeg -i origen.mov -c:v libvpx-vp9 -pix_fmt yuva420p -b:v 0 -crf 32 -an salida.webm

# HEVC con alfa, para Safari. Requiere VideoToolbox, es decir macOS.
ffmpeg -i origen.mov -c:v hevc_videotoolbox -allow_sw 1 -alpha_quality 0.9 \
  -tag:v hvc1 -b:v 2M -an salida.mp4

Y el marcado, con el orden importando: el navegador elige la primera fuente que dice poder reproducir, así que el HEVC va primero para que Safari no se quede con el WebM que decodifica sin alfa.

<video autoplay loop muted playsinline disablepictureinpicture
       poster="/animaciones/poster.webp" class="ilustracion">
  <source src="/animaciones/pieza.mp4" type="video/mp4; codecs=hvc1" />
  <source src="/animaciones/pieza.webm" type="video/webm" />
</video>
.ilustracion { inline-size: 320px; block-size: auto; pointer-events: none; }

@media (prefers-reduced-motion: reduce) {
  .ilustracion { display: none; }
  .ilustracion + .fallback-estatico { display: block; }
}

Cuatro detalles que hacen que funcione en el mundo real:

  • muted y playsinline son obligatorios para que autoplay no sea bloqueado en móvil.
  • poster evita el hueco vacío mientras carga y da algo que enseñar si el vídeo falla.
  • disablepictureinpicture y pointer-events: none impiden que una ilustración decorativa se comporte como un reproductor.
  • Con movimiento reducido, un vídeo en bucle es exactamente lo que hay que quitar. El preload conviene dejarlo en none y activarlo con IntersectionObserver si la pieza está abajo.

Lo que pierdes: no escala más allá de su resolución, no puedes recolorear, y el fichero pesa más que un JSON. Lo que ganas: puedes usar cualquier efecto que exista, y el coste por fotograma de tu hilo principal es cero.

Rive

Rive es la única alternativa que compite con Lottie en su propio terreno, y conviene entender por qué es distinta en lugar de tratarla como “otro Lottie”.

Lottie es un formato de exportación: se diseñó para transportar una composición de After Effects, una herramienta de vídeo, a un reproductor web. Todo lo que tiene de raro —los tiempos en fotogramas, los efectos que no caben, el hecho de que sea lineal— viene de ahí. Rive es un editor propio con un formato pensado desde cero para tiempo de ejecución interactivo: en lugar de una línea de tiempo lineal exporta una máquina de estados con entradas, de modo que la animación reacciona a variables de tu aplicación en lugar de reproducirse.

import { Rive } from "@rive-app/canvas";

const r = new Rive({
  src: "/animaciones/boton.riv",
  canvas: document.querySelector("#lienzo"),
  autoplay: true,
  stateMachines: "Interaccion",
  onLoad: () => {
    const entradas = r.stateMachineInputs("Interaccion");
    const encendido = entradas.find((e) => e.name === "encendido");
    document.querySelector("#interruptor")
      .addEventListener("change", (e) => { encendido.value = e.target.checked; });
  },
});

Los ficheros son binarios y notablemente más pequeños que un JSON equivalente, y el runtime es un motor propio compilado a WebAssembly con salida a canvas o WebGL. El coste real de adoptarlo no es técnico: es que tu diseñador tiene que aprender otra herramienta y abandonar After Effects para estas piezas. Ese coste es alto y a menudo decisivo, y es la razón principal por la que Lottie sigue siendo el estándar de facto pese a ser peor formato para el trabajo interactivo.

💡
La pregunta que separa Lottie de Rive

¿La animación reacciona a algo del estado de tu aplicación, o solo se reproduce? Si la respuesta es reaccionar —un interruptor que se mueve con el valor, un personaje que cambia según el progreso, un botón con cinco estados—, estás intentando forzar en Lottie algo para lo que Rive existe, y vas a acabar escribiendo código que salta entre segmentos por índice de fotograma. Si solo se reproduce, Lottie está bien.

Cuándo Lottie es lo correcto

Después de todo lo anterior, hay un caso en el que Lottie gana y es un caso frecuente:

Una ilustración vectorial con muchos elementos, hecha por una persona de diseño, que va a cambiar varias veces, que tiene que escalar a cualquier densidad y que no necesita reaccionar a nada. Ese es el punto dulce exacto. Nadie va a escribir a mano una ilustración de ochenta formas; un vídeo no escala ni permite fondo transparente sobre cualquier color; un sprite pesa demasiado a los tamaños grandes; y Rive obliga a cambiar de herramienta. Lottie hace justo eso y lo hace bien.

Los casos en los que hay que decir que no, con la alternativa concreta:

Caso Alternativa mejor Por qué
Spinner o indicador de carga CSS puro Cuatro líneas al compositor frente a un intérprete completo
Icono que cambia de estado SVG con CSS o vista previa de dos SVG Menos de diez formas
Ilustración con efectos raster Vídeo con alfa El formato no los soporta y el exportador los tira en silencio
Elemento interactivo con estados Rive o código Lottie no tiene modelo de estados
Pieza en el primer pintado Imagen estática y animar después El parseo bloquea el hilo principal
Bucle infinito decorativo de fondo Nada, o vídeo El coste continuo no se justifica con lo que aporta

Ese último merece una frase. Un bucle infinito es la peor forma posible de gastar el presupuesto de la lección El coste real en runtime: consume el hilo principal durante toda la sesión a cambio de un adorno que el usuario deja de ver a los diez segundos. Si tiene que estar, que sea un vídeo, y que se pare cuando salga de la pantalla.

La herramienta del diseñador no debería determinar la técnica de entrega

La decisión de usar Lottie casi nunca se toma: se hereda. Alguien anima en After Effects porque es la herramienta que conoce, exporta con Bodymovin porque es lo que se hace, y para cuando el fichero llega a un ingeniero la pregunta técnica ya está contestada por omisión. Es exactamente el mismo mecanismo por el que durante años se subieron imágenes de dos mil píxeles a las páginas: no había una decisión mala, había una decisión que nadie tomó. Y produce el resultado peor de forma sistemática, porque la herramienta de origen y la técnica de entrega son dos elecciones independientes que se han fusionado por costumbre. Una animación hecha en After Effects se puede entregar como Lottie, como vídeo con alfa, como hoja de sprites o como referencia para reescribirla en CSS, y las cuatro opciones son técnicamente accesibles desde el mismo fichero de origen; lo único que cambia es qué se exporta. La consecuencia práctica es que el momento de decidir la técnica de entrega no es cuando llega el JSON: es en el brief, antes de que se anime nada, y la conversación no es “¿podéis hacerlo más ligero?” sino “¿esto necesita escalar, recolorearse y reaccionar, o solo reproducirse?”. Un equipo que hace esa pregunta al principio acaba con Lottie en las tres piezas donde aporta y con CSS, sprites y vídeo en las quince donde no, y ninguna de esas quince le cuesta un milisegundo de hilo principal. Un equipo que no la hace acaba con dieciocho Lottie, un presupuesto de rendimiento roto y una discusión recurrente sobre si Lottie es lento, que es la discusión equivocada: Lottie hace exactamente lo que dice hacer, y el problema es que se lo pedimos quince veces de más.