Durante años, animar el paso de una vista a otra exigía una biblioteca dedicada y código extra. La API View Transitions traslada ese trabajo al navegador: toma una instantánea del estado anterior, otra del nuevo e interpola entre ambas. Existe en dos variantes, una para las aplicaciones de página única y otra para la navegación entre páginas, y se adopta sin riesgo gracias a una degradación limpia.
Dos API bajo un mismo nombre
El término abarca dos mecanismos próximos pero distintos. La transición dentro de una misma página (same-document) se aplica cuando el JavaScript modifica el DOM sobre la marcha, típicamente en una aplicación de página única. La transición entre páginas (cross-document) se aplica en una navegación clásica de una URL a otra, siempre que ambas páginas compartan el mismo origen. Ambas se apoyan en el mismo motor de renderizado y en los mismos selectores, lo que reduce lo que hay que aprender.
La buena noticia cabe en una línea: si el navegador no sabe animar, la página se actualiza igualmente.
Animar una transición dentro de una misma página
El punto de entrada es document.startViewTransition. La función recibe una devolución de llamada encargada de modificar el DOM; el navegador captura la pantalla antes de la llamada, ejecuta la devolución, captura la pantalla después y anima el cambio. La detección de la función basta para garantizar el repliegue.
function mettreAJourVue(donnees) {
// remplace le contenu du DOM ici
}
if (!document.startViewTransition) {
mettreAJourVue(donnees); // repli : mise a jour sans animation
} else {
document.startViewTransition(() => mettreAJourVue(donnees));
}
Sin personalización, el navegador aplica un fundido cruzado en toda la página. Ya resulta útil para un cambio de pestaña, una ordenación de lista o la apertura de un panel, donde un corte brusco perjudicaba la lectura.
Encadenar dos páginas sin JavaScript
La transición entre páginas no exige ningún script. Se activa desde CSS, en las dos páginas implicadas, mediante una regla de activación. La navegación debe permanecer en el mismo origen; un enlace a otro dominio no dispara ninguna transición.
/* opt-in : transitions entre pages de meme origine */
@view-transition {
navigation: auto;
}
A partir de ahí, un simple clic en un enlace interno produce un fundido entre la página antigua y la nueva, sin biblioteca de enrutamiento ni renderizado en el cliente. Para un sitio editorial o una tienda con páginas clásicas, es la ganancia más inmediata.
Hacer que un elemento persista de una vista a otra
El efecto más llamativo es el morphing: una miniatura que crece hasta convertirse en la imagen de cabecera de la página siguiente, por ejemplo. Basta con dar el mismo view-transition-name al elemento de origen y al de destino. El navegador entiende que es el mismo objeto y lo anima de una posición a otra.
.carte-article img {
view-transition-name: visuel-article;
}
::view-transition-old(visuel-article),
::view-transition-new(visuel-article) {
animation-duration: 300ms;
}
Cada nombre debe ser único dentro de una vista dada. El navegador genera entonces un árbol de pseudoelementos: ::view-transition-group(), ::view-transition-old() y ::view-transition-new(), que se seleccionan en CSS para ajustar duración, curva o trayectoria. La raíz de la página lleva el nombre reservado root, lo que permite personalizar el fundido global.
Personalizar la animación y respetar las preferencias
Como los pseudoelementos se animan con reglas CSS ordinarias, se aplica toda la herramienta habitual: animation, @keyframes, retardos. La contrapartida es una responsabilidad de accesibilidad: una animación demasiado marcada molesta a parte de los usuarios. La consulta prefers-reduced-motion debe cortar las transiciones para quien lo haya pedido.
@media (prefers-reduced-motion: reduce) {
::view-transition-group(*),
::view-transition-old(*),
::view-transition-new(*) {
animation: none !important;
}
}
Esa precaución no cuesta casi nada y evita convertir una mejora en un obstáculo. Vale para cualquier animación, no solo para View Transitions.
Un ejemplo concreto: de la lista al detalle
El caso más elocuente es el paso de una cuadrícula de artículos a la página de un artículo. En la cuadrícula, la miniatura lleva un nombre de transición; en la página de detalle, la imagen de cabecera lleva el mismo nombre. Al hacer clic, el navegador enlaza ambas y hace crecer la miniatura hasta su posición final mientras el resto de la página se funde. El usuario conserva el hilo visual: ve de dónde procede el contenido que consulta, lo que reduce la carga mental de una navegación.
Para que el efecto se mantenga nítido, el nombre debe estar presente en un solo elemento a la vez en cada vista. Si varias miniaturas comparten el mismo nombre en el mismo instante, el navegador ya no sabe cuál animar y abandona la transición. La regla práctica es componer el nombre a partir de un identificador único, por ejemplo el slug del artículo, en lugar de un valor fijo reutilizado en todas partes.
Los errores que conviene conocer
Se repiten tres errores. El primero es el nombre de transición duplicado, que anula la animación en silencio. El segundo son los desplazamientos de maquetación: si el contenido se reorganiza durante la captura, la instantánea congela un estado intermedio y la animación parece saltar. Es mejor reservar las transiciones para cambios en los que la estructura permanece estable. El tercero es el coste: cada elemento con nombre genera sus propias instantáneas, y multiplicar los nombres en una misma vista recarga el renderizado sin beneficio visible. Unos pocos elementos clave casi siempre bastan.
Un último reflejo evita muchos disgustos: una transición nunca debe enmascarar un tiempo de carga real. Si la página siguiente espera datos, la animación se reproduce sobre una pantalla incompleta y transmite lentitud. La API reviste una navegación ya lista; no sustituye ni a un estado de carga ni a un indicador de espera.
Probada con esos reflejos, la API cumple: hace más legible una interfaz sin añadir deuda y se retira por sí sola allí donde el navegador todavía no la acompaña.
Estado del soporte y estrategia de adopción
Las transiciones dentro de una misma página alcanzaron el estado Baseline en octubre de 2025 y funcionan en los principales navegadores. Las transiciones entre páginas están disponibles en los navegadores Chromium y en Safari reciente, mientras que Firefox todavía trabaja en ellas. Como la API se repliega limpiamente, nada impide adoptarla hoy como mejora progresiva.
| Funcionalidad | Chrome / Edge | Safari | Firefox |
|---|---|---|---|
| Transiciones en una misma página | 111+ | 18+ | 133+ |
| Transiciones entre páginas | 126+ | 18.2+ | en curso |
Referencia. La transición entre páginas se limita a navegaciones del mismo origen y no sustituye a un enrutador de aplicación: reviste una navegación que ya existe. Trátala como una capa decorativa, nunca como una dependencia funcional.
Lo que conviene recordar
View Transitions cubre dos necesidades con una misma gramática: animar una actualización del DOM en una aplicación de página única y suavizar la navegación entre páginas clásicas. La primera variante está ampliamente disponible; la segunda avanza rápido. En ambos casos la API se limita a mejorar lo existente sin romperlo, lo que la convierte en candidata ideal para una adopción prudente: conéctala donde aporte claridad y córtala donde el movimiento estorbe.
He sustituido varias dependencias de animación por esta API en proyectos recientes, y el balance es claro: menos JavaScript, un renderizado más cercano al nativo y un comportamiento previsible. Mi única salvaguarda es no hacer que una funcionalidad dependa de la propia transición. La trato como azúcar visual, probada con el movimiento reducido activado, y compruebo que la página siga siendo usable si la animación no se reproduce. En esas condiciones, es una de las pocas novedades que activo sin dudar en producción. — Simon Janvier
Para profundizar
Documentación de referencia, MDN Web Docs: developer.mozilla.org — View Transition API
