Rive vs Lottie: performance e tamanho do runtime

Quem realmente fez benchmark de Rive vs Lottie?

Pouquíssimas pessoas, e esse é o fato mais importante desta página. Quase todo número de performance ou tamanho que você vai ver em um artigo "Rive vs Lottie" vem de uma de três fontes: o Rive, a LottieFiles ou um único teste independente da consultoria Callstack.

Os números dos fornecedores não são inúteis. Eles mostram o que cada equipe otimizou. Mas nenhum deles compara as duas ferramentas nas mesmas condições, e os números da LottieFiles e da Margelo nem chegam a comparar com a outra ferramenta. Trate a tabela como uma lista de hipóteses a testar, não como um veredito.

O que a Callstack mediu no Android?

A Callstack criou a mesma animação no Lottie e no Rive e rodou as duas em um app React Native em um Sony Xperia Z3, celular lançado em 2014. O Lottie rodou a cerca de 17 FPS tanto na thread JavaScript quanto na thread de UI; o Rive se manteve em cerca de 60 FPS. O resumo da Callstack foi que o Rive superou o Lottie "em todos os quesitos, exceto memória gráfica".

As limitações importam tanto quanto a manchete:

• Um único aparelho. Um celular Android antigo e lento amplia diferenças de CPU que um celular moderno poderia esconder.
• Um único framework. O teste mediu os wrappers de React Native da época, não o Android nativo nem a web.
• A memória foi no sentido oposto. A memória total foi de 276 MB no Rive e 246 MB no Lottie.
• É de 2023. Os dois runtimes mudaram desde então: o pacote React Native do Rive foi reescrito, e a LottieFiles agora oferece um player dotLottie baseado em ThorVG.

A Callstack também recriou um arquivo Lottie de 24,37 KB como um .riv de 2 KB. É um dado independente sobre tamanho de arquivo, mas é uma única animação pequena. Ele sustenta a direção da afirmação do Rive sem confirmar a proporção exata.

A leitura honesta: em um aparelho fraco, com uma animação vetorial de complexidade moderada, o Rive manteve a taxa de frames onde o Lottie não conseguiu, com um custo modesto de memória. Se isso vale para a sua animação e os seus aparelhos, só o seu próprio teste pode dizer.

Por que o Rive parece mais pesado no profiling do Xcode?

Porque as duas bibliotecas fazem o trabalho em lugares diferentes. O runtime do Rive para Apple desenha diretamente com Metal, dentro do processo do seu app. O engine Core Animation do Lottie entrega as camadas ao render server da Apple, que roda em um processo separado do sistema chamado backboardd.

Se você abrir o Instruments e analisar só o seu app, o custo de renderização do Rive aparece no seu processo, e boa parte do custo do Lottie não. A própria documentação do Rive aponta isso e orienta os desenvolvedores a analisar o backboardd além do app. Essa orientação vem de um fornecedor, e a página não traz números, mas a arquitetura por trás é fácil de confirmar: no iOS, a composição do Core Animation acontece fora do app.

Para uma comparação justa no iOS:

• Registre CPU e GPU tanto do processo do seu app quanto do backboardd.
• Teste em um aparelho físico, não no Simulator.
• Reproduza a mesma animação, no mesmo tamanho na tela, pela mesma duração.
• Observe o impacto energético, não só o pico de CPU, porque um mascote em loop fica rodando por minutos.

O mesmo princípio vale em outros contextos. Qualquer comparação que mede só um processo, ou só o primeiro segundo de reprodução, pode enganar para qualquer um dos lados.

O Lottie resolveu o problema de CPU no iOS?

Em grande parte, para animações compatíveis. Versões antigas do lottie-ios renderizavam cada frame na thread principal, e os mantenedores observaram que esse motor podia usar cerca de 5% a 20% de CPU, ou mais. No lottie-ios 4.0 (fim de 2022), o Airbnb tornou o motor de renderização Core Animation o padrão por meio da configuração .automatic. O Core Animation reproduz a animação sem trabalho por frame na sua thread principal.

O detalhe está na palavra "compatíveis". Se uma animação usa recursos que o motor Core Animation não suporta, o lottie-ios volta para o motor da thread principal naquele arquivo. Por isso, dois arquivos Lottie do mesmo designer podem ter performances bem diferentes no iPhone, dependendo dos recursos do After Effects que usam.

Isso também explica por que tópicos antigos de fóruns sobre o Lottie drenando bateria no iOS podem não descrever o comportamento atual. Antes de migrar um app do Lottie por motivos de performance, verifique qual motor seus arquivos realmente usam e qual versão do lottie-ios você distribui. A solução pode ser uma atualização ou uma exportação mais simples, e não um novo formato.

O teste da Callstack de 2023 rodou no Android, então não diz como nenhuma das ferramentas se sai em um iPhone atual.

Qual o tamanho dos runtimes do Rive, lottie-web e dotLottie?

O tamanho do arquivo é só metade do download. Todo formato também precisa de um player, e o player muitas vezes é maior que a animação.

Dois pontos chamam a atenção. Primeiro, nossa medição do arquivo WASM atual do canvas-lite é maior que o número publicado pelo Rive, que pode ser anterior à versão atual. Segundo, o lottie-web é o menor player da lista, mas sua última publicação foi em maio de 2025, e a LottieFiles agora promove os players dotLottie, cujo motor WASM é mais pesado que o lottie-web.

Para uma única animação, o player mais leve costuma vencer. Para muitas animações, ou um personagem com muitos estados, a economia por arquivo começa a superar o custo do runtime.

O renderizador (Canvas2D, WebGL2, Rive Renderer) muda o resultado?

Sim, e esse é mais um motivo para um único benchmark raramente valer para outras configurações. Na web, os pacotes @rive-app/canvas e canvas-lite do Rive desenham com a API Canvas2D do navegador, enquanto o @rive-app/webgl2 usa o Rive Renderer na GPU. A documentação do Rive diz que alguns recursos, incluindo o Vector Feathering, precisam do Rive Renderer. No Apple, no Android e no React Native, o Rive Renderer é o padrão.

O Lottie também tem suas variações. O lottie-web pode renderizar em SVG, Canvas ou HTML, e cada opção se comporta de um jeito com muitas camadas. Os players dotLottie renderizam com o ThorVG compilado para WASM, e também há builds com WebGL e WebGPU. No iOS, o lottie-ios escolhe, para cada arquivo, entre o Core Animation e seu motor na thread principal.

Ou seja, "Rive vs Lottie" é, na verdade, um comparativo entre um pacote, um renderizador e um dispositivo específicos. Um teste que usou o renderizador de GPU do Rive contra o renderizador SVG do lottie-web diz pouco sobre canvas-lite contra dotLottie. Ao ler um benchmark, procure primeiro os nomes dos pacotes. Se eles não aparecem, fica difícil aplicar o resultado.

O Rive também tem uma otimização de runtime que vale conhecer: suas state machines podem "assentar" (settle), ou seja, o runtime detecta que nada vai mudar e para de avançar os frames. Uma animação idle do Rive que já assentou custa muito pouco.

Como fazer o benchmark da sua própria animação?

Use sua animação real nos seus dispositivos reais. Um checklist rápido:

1. Use o mesmo conteúdo. Crie ou exporte a mesma animação nos dois formatos, com o mesmo tamanho de artboard e a mesma taxa de frames.
2. Meça o download total. Some o arquivo de animação comprimido ao runtime comprimido, do jeito que sua CDN os entrega.
3. Teste no seu dispositivo-alvo mais fraco. Um celular Android intermediário revela mais que um topo de linha novo.
4. Registre taxa de frames, CPU e memória ao longo do tempo. Rode cada um por pelo menos um minuto. No iOS, inclua o backboardd.
5. Teste seu layout real. Dez animações pequenas em uma página se comportam de forma diferente de uma grande.
6. Verifique o custo em repouso. Uma animação pausada ou assentada deve consumir quase nada.

Se você está escolhendo um formato para um personagem, e não para um único clipe, conte também os arquivos. Um conjunto de loops e reações em um único arquivo Rive é uma requisição e um parse; o mesmo conjunto em arquivos Lottie separados são muitos. Nosso próprio exemplo: um conjunto de personagem do Charmotion reúne 17 animações em um único .riv de cerca de 35 a 45 KB para personagens planos (arte 3D ou renderizada fica maior, porque as imagens vão embutidas), além de cópias em MP4, GIF e WebM/MOV com fundo transparente para os lugares onde nenhum runtime pode ser carregado.

Para os prós e contras além da velocidade, veja Rive vs Lottie: qual usar em 2026.

Qual escolher pensando em performance?

Escolha o Lottie se você publica uma ou duas animações simples na web, onde o player pequeno do lottie-web é difícil de superar; se seus arquivos já rodam no motor Core Animation do lottie-ios sem fallback; ou se o pipeline da sua equipe é o After Effects e as animações têm boa performance nos testes.

Escolha o Rive se você precisa de muitos estados ou animações de um mesmo personagem, se a performance em Android de entrada importa, ou se o seu próprio teste reproduz a diferença de taxa de frames que a Callstack observou. A economia por arquivo e as state machines que assentam compensam mais quando o runtime é compartilhado por muitas animações.

Em qualquer caso, decida com números medidos no seu próprio app e refaça os testes depois de grandes atualizações de runtime. Os dois projetos estão evoluindo rápido: o runtime de React Native do Rive foi reescrito sobre Nitro Modules, e a LottieFiles agora direciona projetos novos para seus players dotLottie baseados em ThorVG. Um resultado de dois anos atrás pode não descrever mais nenhuma das ferramentas.

Perguntas frequentes

O Rive é mais rápido que o Lottie?

Com frequência, mas depende da animação, do dispositivo e do pacote. O teste independente da Callstack em 2023 mediu cerca de 60 FPS para o Rive e 17 FPS para o Lottie em um Sony Xperia Z3 no React Native, enquanto o Rive usou um pouco mais de memória. Não encontramos nenhum comparativo independente mais recente, então teste seus próprios arquivos.

Os arquivos Rive são mesmo 10 a 15 vezes menores que os do Lottie?

Essa proporção é uma afirmação da própria Rive, sem metodologia publicada. A Callstack recriou de forma independente um Lottie de 24,37 KB como um .riv de 2 KB, o que aponta na mesma direção. A LottieFiles diz que arquivos .lottie comprimidos reduzem a diferença. Compare o tamanho do arquivo comprimido mais o runtime para a sua própria animação.

Qual player web é o menor?

O lottie-web tem cerca de 76 KB em gzip na build completa e 46 KB na build light, segundo nossa medição de outubro de 2026. O pacote web mais leve do Rive, o canvas-lite, tem 222 KB brotli pelos números do Rive e cerca de 373 KB pelos nossos. O player WASM do dotLottie tem cerca de 433 KB brotli.

Por que o Lottie parece mais barato que o Rive no Instruments?

O motor Core Animation do Lottie renderiza no processo backboardd da Apple, fora do seu app, enquanto o Rive desenha com Metal dentro do seu app. Analisar só o seu app esconde parte do custo do Lottie. A documentação do Rive recomenda analisar também o backboardd, o que é uma boa prática para qualquer comparativo justo no iOS.

Respostas rápidas deste guia

• O Rive é mais rápido que o Lottie?
• Os arquivos Rive são menores que os arquivos Lottie?
• Qual é o tamanho do runtime do Rive?
• O Lottie no iOS ainda usa muita CPU?

Fontes

• Lottie vs. Rive: Optimizing Mobile App Animation, Callstack
• Apple runtime: Resource usage, Rive
• Runtime sizes, Rive
• Choose a renderer, Rive
• lottie-ios 4.0.0 release notes, Airbnb (GitHub)
• lottie-web on npm, npm
• @lottiefiles/dotlottie-web on npm, npm
• Rive as a Lottie alternative, Rive