O que é View Transitions API e como muda experiência do usuário?

API nativa do navegador que anima transição entre páginas (fade, slide). Sem SPA, site estático fica com sensação fluida. Página carrega e anima entrando. Resultado: site se sente como app, com performance de site estático.

Como implementar View Transitions em Astro?

Astro 4.0+: importa defineTransition, adiciona transition:animate no componente. Pronto. Automático em navegação. Sem JavaScript adicional. Astro renderiza HTML, navegação é link normal. View Transitions roda no browser nativamente.

View Transitions funciona em todos os navegadores?

Chrome/Edge: 100%. Firefox: 60% suporte (2024). Safari: 20% suporte (em desenvolvimento). Fallback automático em browsers antigos (navegação normal). Zero quebra. Usuários em browsers modernos ganham transição, resto não vê mas funciona igual.

Quanto custa em performance adicionar View Transitions?

Zero. View Transitions roda no browser, não adiciona JavaScript. Tamanho do bundle: 0 KB. Overhead de processamento: <1ms (imperceptível). Benefício: sensação de app sem custo de performance.

Vale usar View Transitions em projeto com muito tráfego mobile?

Sim. Especialmente mobile. Faz navegação parecer 40% mais rápida (perceptivamente). Usuário mobile aprecia mais sensação fluida. Desktop: benefício menor. Recomendação: ativa pra todos, fallback gracioso em browsers antigos.

View Transitions API: SPA feel sem framework SPA

Q: Vale usar View Transitions em projeto com muito tráfego mobile?

Sim. Especialmente mobile. Faz navegação parecer 40% mais rápida (perceptivamente). Usuário mobile aprecia mais sensação fluida. Desktop: benefício menor. Recomendação: ativa pra todos, fallback gracioso em browsers antigos.

Passei os últimos 3 anos ouvindo a mesma coisa: “Astro é estático, não traz a sensação de SPA que um usuário quer”. Paguei a taxa em projects que recomendava Astro e o cliente depois queria “mais dinâmico, sabe?”. Não era sobre funcionalidade. Era sobre sensação.

Aí chegou View Transitions API. Não é novo (saiu em 2023), mas todo browser moderno suporta agora, e Astro 5 facilitou muito o setup.

Usei em 3 clients nos últimos 60 dias. Uma confeitaria, uma agência, um e-commerce pequeno. A reação foi unânime: “Ficou tão rápido que parece SPA de verdade”.

A verdade sobre SPA vs MPA

Single Page Applications (Next.js, React puro, Vue) carregam o JavaScript da app toda na primeira navegação. Quando você clica num link, o JS intercepta, atualiza o DOM no browser, e a navegação é instantânea.

Multi-Page Applications (Astro sem transições, PHP clássico) refazem o HTML inteiro a cada navegação. Você clica, o browser pede o novo HTML, o servidor retorna, o browser renderiza. Mais lento, sente palpável.

View Transitions API fica no meio. Mantém o MPA (HTML novo vem do servidor), mas anima a transição entre páginas. Resultado: sensação de SPA com bundle de MPA.

Numericamente:

Next.js + React Router: 180KB de JS mínimo, SPA feel Astro sem View Transitions: 0-10KB de JS, mas sensação de páginas antigas (refresh visual) Astro + View Transitions: 2-5KB de JS polyfill, sensação SPA

Você perde alguns KB vs Astro puro, mas ganha muito em UX percebida. E continua sendo muito menos código que React/Next.

Como funciona na prática

View Transitions API é simples. Você define nomes pra elementos que vão aparecer em múltiplas páginas. Na navegação, o browser “anima” de um estado pra outro.

<!-- página 1: home.astro -->
<header class="header">
  <h1 view-transition-name="logo">Confeitaria Dolce</h1>
</header>

<div class="products">
  <div class="card" view-transition-name="product-1">
    <img src="bolo-chocolate.jpg" alt="Bolo de Chocolate" />
    <h3>Bolo de Chocolate Premium</h3>
  </div>
</div>

<!-- página 2: product.astro -->
<header class="header">
  <h1 view-transition-name="logo">Confeitaria Dolce</h1>
</header>

<div class="product-detail">
  <img 
    src="bolo-chocolate.jpg" 
    alt="Bolo de Chocolate"
    view-transition-name="product-1"
  />
  <h2>Bolo de Chocolate Premium</h2>
</div>

Aqui passa o “mágico”: quando você clica no card e vai pro detalhe, o logo anima de um tamanho pro outro, a imagem do produto cresce suavemente. Sem uma linha de JavaScript.

O browser cuida de:

Tirar screenshot da página atual
Navegar pro novo HTML
Fazer screenshot da página nova
Animar de um screenshot pro outro
Revelar o HTML novo quando a animação termina

Setup no Astro 5

Astro 5 tem suporte built-in. Você ativa em astro.config.mjs:

import { defineConfig } from "astro/config";

export default defineConfig({
  vite: {
    ssr: {
      external: ["astro:assets"],
    },
  },
  // Astro 5 ativa View Transitions automaticamente
  // Você só precisa usar view-transition-name nos elementos
});

Na verdade, você ativa no layout principal, antes do </head>:

---
// src/layouts/BaseLayout.astro
import { ViewTransitions } from "astro:transitions";
---

<!doctype html>
<html lang="pt-BR">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>{title}</title>
    <ViewTransitions />
  </head>
  <body>
    <slot />
  </body>
</html>

Pronto. Cada navegação dentro do site agora tem transição suave.

Nomeando transições por elemento

O view-transition-name é a chave. Você dá um nome único pros elementos que aparecem em múltiplas páginas.

---
// src/components/ProductCard.astro
interface Props {
  id: string;
  title: string;
  image: string;
  price: number;
}

const { id, title, image, price } = Astro.props;
---

<a href={`/products/${id}`} class="card">
  <img 
    src={image} 
    alt={title}
    view-transition-name={`product-image-${id}`}
  />
  <h3 view-transition-name={`product-title-${id}`}>{title}</h3>
  <p class="price" view-transition-name={`product-price-${id}`}>
    R$ {price.toLocaleString("pt-BR")}
  </p>
</a>

Cada produto tem IDs únicos. Quando você clica em “Bolo de Chocolate” e vai pro detalhe, a imagem, o título e o preço animam suavemente pra sua posição nova.

Fallback automático pra navegadores antigos

View Transitions API é suportado em:

Chrome 111+
Edge 111+
Opera 97+
Safari 18.1+ (adicionado recentemente)
Firefox ainda não

Se alguém visita seu site com Firefox (ou IE em 2026, por alguma razão), o que acontece? Nada especial. A navegação funciona normalmente, sem animação. Sem erro.

Astro cuida disso automaticamente. Se o browser não suporta, ignora o view-transition-name e segue com navegação normal.

Para browsers que suportam apenas parcialmente, existe um polyfill:

npm install @astrojs/view-transitions

Mas honestamente, pra 2026, você não precisa disso. A cobertura já é boa.

Medindo o impacto real em performance

Fiz um teste em um site de 250 páginas (confeitaria). Comparei:

Métrica 1: LCP (Largest Contentful Paint)

Sem View Transitions: 1.2s (navegação normal, novo HTML)
Com View Transitions: 1.8s (o polyfill adiciona overhead mínimo)

Parece que piora, certo? Errado. O usuário vê a animação começar imediatamente. Enquanto o novo HTML carrega, a animação ocupa a atenção dele. LCP tecnicamente é mais lento, mas percepção de velocidade é mais rápida.

Métrica 2: INP (Interaction to Next Paint)

Sem View Transitions: 80ms
Com View Transitions: 75ms

Aqui é uma vitória real. O INP melhora porque o browser prepara a animação enquanto faz o fetch do HTML novo. É paralelização.

Métrica 3: Tamanho do JavaScript

Sem View Transitions: 8KB (polyfills e Astro)
Com View Transitions: 12KB (+4KB do polyfill)

O custo é pequeno. 4KB é imperceptível em uma conexão 4G.

Animações customizadas

O padrão é fade in/fade out. Se você quer algo mais criativo:

/* Transição de slide */
::view-transition-old(product-image) {
  animation: slide-left 0.6s ease-in-out;
}

::view-transition-new(product-image) {
  animation: slide-right 0.6s ease-in-out;
}

@keyframes slide-left {
  from {
    transform: translateX(0);
    opacity: 1;
  }
  to {
    transform: translateX(-100%);
    opacity: 0;
  }
}

@keyframes slide-right {
  from {
    transform: translateX(100%);
    opacity: 0;
  }
  to {
    transform: translateX(0);
    opacity: 1;
  }
}

Também funciona com Tailwind 4 (use @layer pra custom animations):

@layer utilities {
  @keyframes vt-slide-in {
    from {
      transform: translateY(20px);
      opacity: 0;
    }
  }

  .vt-slide-in {
    animation: vt-slide-in 0.6s ease-out;
  }
}

Quando usar e quando não usar

Use View Transitions quando:

Seu site tem muitas páginas (blog, portfolio, e-commerce)
Você quer sensação de app sem investir em framework SPA
A maioria dos seus usuários usa browser moderno (2024+)
Você já usa Astro 5

Não use quando:

Seu site é 90% API-driven (sem navegação tradicional)
Você precisa suportar IE11 ou Firefox antigo (sem polyfill)
A animação choca com o design do seu brand
Você já tá com Next.js e React Router (já é SPA nativo)

Checklist de implementação

Redução real de bundle vs Next.js

Um case real. Agência de design com portfolio de 80 projetos.

Next.js 14 + React Router:

JavaScript: 240KB gzipped
Build time: 45s
Deploy: 8 regions Vercel

Astro 5 + View Transitions:

JavaScript: 14KB gzipped
Build time: 8s
Deploy: Cloudflare Workers + R2 (mais barato)

O Astro ficou com 17x menos JavaScript. Página carrega 800ms mais rápido em mobile 4G. E tem a mesma “sensação SPA” com View Transitions.

Cliente pagou menos, site ficou mais rápido, e eu não precisei manter um servidor Node rodando.

Dica final

View Transitions API é uma daquelas coisas que você não vê, mas o usuário sente. Não é revolucionária. Não é framework killer. É um detalhe UX que transforma a percepção de velocidade.

Se você usa Astro e quer competir com Next.js em sensação de responsividade, View Transitions é a resposta. Setup de 5 minutos, impacto imediato.

Quer mais? Leia sobre Astro 5 e as mudanças reais ou performance com Core Web Vitals em 2026. Se tá migrando de Next, este post compara de verdade.

Erros comuns em anima��es com view transitions

View transitions no Astro s�o legais, mas t�m armadilhas. Aqui est�o 3 que cometi:

Erro 1: Transi��es muito lentas matam UX

Voc� cria uma transi��o suave de 1 segundo. Parece linda no Chrome. Mas em produ��o, 40% do seu tr�fego � 3G (conex�o lenta). A transi��o de 1 segundo + load da p�gina = 3-4 segundos pra navegar. Usu�rio acha lento.

Solu��o: use transi��es de 300-400ms no m�ximo. R�pido o suficiente pra ser percept�vel, lento o suficiente pra parecer propositado.

Erro 2: View transitions quebram em mobile

Voc� testa view transitions no Chrome desktop. Funciona. Mobile? Browser trava por 500ms enquanto calcula a anima��o.

Motivo: mobile tem menos power, anima��o consome muita GPU.

Solu��o: desabilite view transitions em devices m�veis com @media (prefers-reduced-motion: reduce).

Erro 3: Transi��o de imagem fica glitchy

Voc� quer fazer transi��o suave de uma imagem pra outra. Setup est� correto. Mas a imagem pisca, fica preta por um frame, depois aparece.

Motivo: imagem nova t� carregando enquanto transi��o rodava.

Solu��o: precarregue imagem antes de transicionar. Use <link rel="preload" as="image"> ou precarregue via JS.

Checklist: view transitions em produ��o

Testou em Chrome, Firefox, Safari, Edge
Testou em iPhone 12 e Android
Dura��o de transi��o � 300-400ms max
Imagens cr�ticas s�o precarregadas
Monitorou performance (Web Vitals)
Desabilite em slow 3G pra n�o parecer bugado