O Impacto das CSS View Transitions no Desempenho Web

O Impacto da View Transition API no Desempenho

A View Transition API permite que os desenvolvedores habilitem transições visuais suaves entre visualizações no mesmo site, mesmo para aplicativos de várias páginas (MPAs). Essas view transitions são gerenciadas por transições CSS entre duas visualizações de página. Historicamente, transições CSS durante o carregamento da página causam um atraso na métrica LCP. Suspeitávamos que essas view transitions entre páginas também tivessem implicações de desempenho, particularmente em dispositivos móveis e CPUs mais lentas. Nossos dados de Real User Monitoring (RUM) confirmaram essas suspeitas, juntamente com outros insights interessantes sobre o efeito nos Core Web Vitals, especialmente no Largest Contentful Paint (LCP).

Última revisão por Arjen Karel em fevereiro de 2026

Descobertas dos Dados de RUM

Para validar nossa ideia de que as view transitions impactam negativamente o Largest Contentful Paint, configuramos uma série de testes A/B em 5 sites diferentes e os deixamos rodar por 7 dias. Em 50% das visualizações de página, adicionamos @view-transition { navigation: auto;} às folhas de estilo da página, enquanto os outros 50% das visualizações de página foram servidos sem esses estilos.

Coletamos mais de 500.000 visualizações de página, onde, por fim, 120.000 visualizações de página em dispositivos móveis foram analisadas porque se originaram de navegações móveis dentro do mesmo site.

Dados de monitoramento de usuários reais descobriram que a implementação da View Transition API adiciona aproximadamente 70ms ao Largest Contentful Paint para visualizações de página repetidas em dispositivos móveis. Esse aumento no tempo do LCP é digno de nota, considerando a recomendação do Google de que o LCP deve ocorrer dentro de 2,5 segundos a partir do momento em que a página começa a carregar para uma boa user experience.

Correlação de Desempenho da CPU

Tendo confirmado o impacto negativo das view transitions no LCP, investigamos mais a fundo. Procedemos à configuração de uma série de experimentos para testar automaticamente as mesmas 2 páginas com e sem view transitions. Os resultados mostram uma clara correlação entre a velocidade da CPU e o impacto das view transitions no LCP. As descobertas indicam que quanto mais lenta a CPU, mais pronunciado é o efeito negativo no LCP ao usar view transitions.

Se você quiser testar isso por conta própria, visite a nossa página inicial do experimento de view transition no GitHub.

Esses resultados destacam três observações principais:

• View transitions tornam o LCP mais lento: Visualizações de página com view transitions são mais lentas que visualizações de página sem efeitos de view transition.
• A velocidade da CPU é um fator importante: A velocidade da CPU tem uma alta correlação com a diferença de LCP em visualizações com e sem efeitos de view transition. Isso importa especialmente para dispositivos móveis de baixo custo.
• Existe um 'ponto de equilíbrio' de velocidade da página: Com uma desaceleração de 6x, o LCP tem um melhor desempenho sem cache de rede. A razão simples é que nesta velocidade da CPU, o elemento do LCP ainda não foi decodificado sem o cache de rede e a transição é aplicada a uma página em branco. Imediatamente após a transição mais simples para uma página em branco, o elemento do LCP é pintado. Aparentemente, este é o ponto de equilíbrio onde é mais eficiente fazer a transição para uma página em branco do que transitar entre imagens. De uma perspectiva de UX, é melhor fazer a transição entre imagens, é claro.

Suporte dos Navegadores

A View Transition API atingiu o status de Baseline Newly Available em outubro de 2025. As view transitions do mesmo documento (same-document) agora funcionam no Chrome 111+, Edge 111+, Firefox 144+ e Safari 18+, cobrindo cerca de 89% do tráfego global de navegadores. As view transitions entre documentos diferentes (cross-document) (aquelas acionadas por @view-transition { navigation: auto; }) têm um suporte um pouco mais restrito, mas funcionam em todos os principais navegadores, exceto em versões mais antigas do Firefox.

Esse amplo suporte significa que mais desenvolvedores adotarão as view transitions, tornando as implicações de desempenho ainda mais relevantes.

Entendendo @view-transition { navigation: auto; }

Tradicionalmente, a implementação de view transitions exigia o uso extensivo de CSS e JavaScript. A View Transition API simplifica esse processo, permitindo que os desenvolvedores definam as transições de forma declarativa. A View Transition API funciona capturando snapshots dos estados antigo e novo de um documento, atualizando o DOM enquanto suprime a renderização e usando animações CSS para executar a transição.

Exemplo de Implementação

Aqui está um exemplo básico de como habilitar cross-document view transitions em seu CSS:

@view-transition {
  navigation: auto;
}

Ou em combinação com uma media query para segmentar dispositivos tablet ou desktop:

@media (min-width: 768px) {
  @view-transition {
    navigation: auto;
  }
}

Esta simples adição permite que o navegador manipule a transição automaticamente ao navegar entre páginas na mesma origem.

Acessibilidade: prefers-reduced-motion

Os usuários que preferem movimentos reduzidos não devem ser forçados a ver animações. Envolva sua regra de view transition em uma media query prefers-reduced-motion. Isso também remove a penalidade de LCP para esses usuários.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Eliminando o Custo de LCP com Speculation Rules

A melhor maneira de usar view transitions sem a penalidade de LCP é combiná-las com a Speculation Rules API. Quando o navegador pré-renderiza a próxima página antes que o usuário clique, a view transition é animada entre dois estados já renderizados. O elemento do LCP já está carregado e decodificado, portanto, a transição não adiciona nenhum atraso mensurável. Se você se importa tanto com a estética quanto com o desempenho, esta é a combinação a ser usada.

Recomendações

A View Transition API oferece transições suaves e visualmente agradáveis entre navegações. Isso pode levar a pequenos benefícios em métricas de negócios, como menores taxas de rejeição e maior engajamento. No entanto, especialmente em dispositivos móveis de baixo custo, os desenvolvedores devem considerar cuidadosamente as implicações de desempenho. Aqui estão as minhas recomendações:

• Verifique seu orçamento de LCP primeiro. Se o seu LCP móvel já estiver acima de 2,0 segundos, adicionar 70ms de sobrecarga de transição o colocará mais perto de falhar. Corrija o LCP primeiro, adicione transições depois.
• Combine com Speculation Rules. A pré-renderização da página de destino elimina totalmente o custo de LCP das view transitions.
• Use prefers-reduced-motion. Envolver as view transitions em uma media query de movimento reduzido respeita as preferências do usuário e remove o custo de desempenho para usuários que não desejam animações.
• Teste com usuários reais. Testes de laboratório não capturam toda a gama de dispositivos e condições de rede que seus visitantes usam. Execute um teste A/B com o CoreDash para medir o impacto real no seu LCP antes e depois de habilitar as view transitions.
• Considere apenas para desktop. Nossos dados mostram que dispositivos desktop com CPUs rápidas não sofrem quase nenhum impacto no LCP (5ms). Restringir as view transitions ao desktop por meio de uma media query min-width é um meio-termo razoável.