Animação na web em 2026: por que tirei a biblioteca de animação dos meus projetos

Resposta direta: em 2026 eu animo a maior parte de um site com CSS e com as APIs nativas do navegador, e só carrego uma biblioteca de animação quando o projeto precisa de gesto ou de física. View Transitions e scroll-driven animations cobrem transição de página, elemento compartilhado e revelação no scroll sem um kilobyte de JavaScript. O resto, que é arrastar, soltar e interromper no meio, continua sendo trabalho de JavaScript.

O que mudou na animação web em 2026

Eu acompanho isso desde que as duas especificações chegaram ao Chrome e ao Edge estáveis, em 2025. O que era demo virou produção rápido: em 2026 já é comum ver transição de página nativa em produto grande, e a conversa dentro dos times deixou de ser "qual biblioteca a gente usa" para "isso aqui precisa mesmo de biblioteca".

View Transitions: transição de página sem gambiarra

A View Transitions API tem duas caras. A versão dentro do mesmo documento, útil em SPA e em troca de estado, já é Baseline, ou seja, dá para usar sem medo nos navegadores atuais. A versão entre documentos, que é a que faz a navegação de um site comum parecer app, chegou ao Safari 18.2 ainda em dezembro de 2024, mas o Firefox segue sem implementar, então em 2026 ela continua fora do Baseline.

Na minha experiência, isso não é motivo para adiar. Eu trato a transição como camada que degrada: no Chrome, no Edge e no Safari a pessoa ganha o movimento; no Firefox ela ganha uma navegação normal, que é exatamente o que já tinha antes. Ninguém quebra, ninguém espera. Vale lembrar que a Navigation API, prima dessa história, virou Baseline em janeiro de 2026, o que deixou o controle de rota bem menos dependente de hack.

Scroll-driven animations: o scroll saiu do JavaScript

A outra metade da mudança é o CSS de scroll timeline, com scroll-timeline e view-timeline. Barra de progresso de leitura, parallax, seção que aparece quando entra na tela: tudo isso eu escrevia com IntersectionObserver e um punhado de listeners. Hoje escrevo em CSS, e roda no compositor, não na main thread. A diferença aparece justamente no celular mediano do cliente, que é onde a animação feita em JavaScript engasgava.

Por que tirei a biblioteca de animação da maioria dos projetos

Aqui no Studio Seu eu costumo abrir o projeto pelo peso, não pelo efeito. E a conta ficou difícil de defender. Uma biblioteca como a Motion, a antiga Framer Motion, que hoje vive em motion.dev e é importada como motion/react, custa algo na casa das dezenas de kilobytes comprimidos para entregar, em muitos sites, três coisas: fade de entrada, transição de rota e stagger de lista. As três já são nativas.

Relatos publicados ao longo de 2026 por times que fizeram essa troca falam em bundle menor em algumas dezenas de kilobytes e LCP algumas centenas de milissegundos melhor. Eu não trato número de terceiro como promessa, cada site é um site, mas a direção bate com o que vejo na bancada: quando a animação sai do JavaScript, a página começa a responder antes.

Tem um ganho menos óbvio, e para mim é o principal: animação nativa é mais fácil de manter. Ela não quebra na atualização major da biblioteca, não briga com o framework da vez e não precisa de wrapper para funcionar em componente de servidor. Site de cliente vive anos, e cada dependência a menos é um problema a menos daqui a dois anos.

O que eu ainda faço com JavaScript

Não virei purista. Tem coisa que o CSS não faz em 2026, e insistir só custa tempo:

• Gesto: arrastar para dispensar, card que segue o dedo, sheet que abre pela metade. Não existe equivalente nativo.
• Física: mola com massa e amortecimento de verdade, quando o movimento precisa parecer objeto e não curva.
• Interrupção: animação que muda de destino no meio do caminho, sem voltar ao começo.
• Coreografia complexa: abertura de home com dez elementos sincronizados, onde uma ferramenta como o GSAP ainda economiza horas.

Minha régua é simples: se o movimento é decorativo ou previsível, é CSS. Se o movimento responde ao dedo da pessoa em tempo real, é JavaScript.

Como eu aplico isso na prática

• Começo o projeto sem nenhuma biblioteca de animação instalada, e só instalo quando um requisito real exigir.
• Trato transição de página como melhoria progressiva, com @view-transition e nada mais.
• Nomeio poucos elementos compartilhados, normalmente capa e título. Nomear tudo deixa a transição confusa e lenta.
• Respeito prefers-reduced-motion desde o primeiro commit, não na revisão de véspera.
• Testo no Firefox de propósito, para garantir que o site sem transição continua bom.

Perguntas frequentes

View Transitions funcionam em todos os navegadores em 2026?

Dentro do mesmo documento, sim, é Baseline. Entre documentos, funciona em Chrome, Edge e Safari, mas não no Firefox, que ainda não implementou. Por isso eu uso como camada extra, nunca como requisito.

Preciso desinstalar minha biblioteca de animação?

Não por moda. Eu removo quando ela está no bundle só para fazer o que o navegador já faz sozinho. Se o produto tem gesto, física ou interrupção, ela continua valendo o espaço que ocupa.

Scroll-driven animation atrapalha a performance?

Ao contrário do equivalente em JavaScript, ela roda fora da main thread. O risco em 2026 não é técnico, é de excesso: página com movimento demais cansa e atrapalha a leitura.

E a acessibilidade?

Movimento é preferência, não detalhe. Toda animação que eu entrego tem um caminho reduzido em prefers-reduced-motion, e nenhuma informação depende só do movimento para ser compreendida.

Se eu tivesse que resumir minha posição em 2026: animação parou de ser um problema de biblioteca e voltou a ser um problema de projeto. A parte técnica ficou barata, então o que separa um site bom de um site cansativo é decisão, não ferramenta. Eu prefiro pouco movimento, bem colocado, que sobrevive a três anos de manutenção.

Se você está com um site pesado de animação e quer entender o que dá para trocar por CSS nativo sem perder personalidade, me chama para conversar. Aqui no Studio Seu esse costuma ser um dos ajustes mais baratos com efeito mais visível.