Las animaciones web han pasado de ser un detalle decorativo a convertirse en una parte importante de la experiencia de usuario. Un cambio de estado, una navegación entre páginas o la apertura de una vista nueva pueden sentirse bruscos si todo aparece y desaparece de golpe. Por eso, durante años, muchas interfaces han intentado suavizar esos cambios con JavaScript, librerías de animación, rutas propias en frameworks SPA o trucos complejos de CSS.
La View Transitions API llega precisamente para simplificar ese escenario. Su objetivo es permitir transiciones entre vistas de una forma más nativa, fluida y controlada, tanto en aplicaciones de una sola página como en sitios multipágina. Dicho de otra forma: nos ayuda a crear animaciones entre páginas con CSS sin tener que reconstruir toda la lógica visual desde cero.
Si trabajas con interfaces modernas, blogs, portfolios, documentación, tiendas online o aplicaciones web, entender esta API puede abrirte una forma mucho más elegante de plantear las transiciones. No se trata de animar por animar, sino de mejorar la continuidad visual y ayudar al usuario a entender qué ha cambiado en pantalla.
Qué es la View Transitions API
La View Transitions API es una API del navegador que permite animar el cambio entre dos estados visuales de una página. Ese cambio puede ocurrir dentro de la misma página, como sucede en una SPA, o entre dos documentos distintos, como ocurre al navegar de una página HTML a otra dentro del mismo sitio.
La idea de base es muy interesante: el navegador captura una especie de “fotografía” del estado anterior y otra del estado nuevo. Después, permite animar la transición entre ambas capturas usando CSS. Así se evita tener que mantener manualmente el contenido antiguo y el nuevo al mismo tiempo dentro del DOM, algo que muchas veces terminaba generando código frágil, difícil de mantener y con posibles problemas de accesibilidad.
En términos prácticos, una view transition puede servir para animar:
- El paso de una página de listado a una página de detalle.
- El cambio entre temas claro y oscuro.
- La reorganización de una galería.
- La navegación entre secciones de una SPA.
- La transición entre páginas de un blog o portfolio.
- El cambio de estado de una tarjeta, modal o componente interactivo.
La clave está en que la API no pretende sustituir a todas las animaciones CSS tradicionales. Más bien, resuelve un problema muy concreto: animar cambios de vista completos o parciales sin tener que duplicar manualmente estructuras ni coordinar estados complejos con JavaScript.
Por qué son importantes las transiciones entre páginas CSS
Durante mucho tiempo, las páginas web tradicionales han tenido una navegación bastante abrupta: haces clic en un enlace, el navegador carga otra página y la pantalla cambia de golpe. Esto es perfectamente funcional, pero no siempre transmite continuidad.
Las SPA, por su parte, popularizaron una experiencia más parecida a las aplicaciones nativas. Al cambiar de ruta sin recargar el documento completo, podían añadir animaciones entre vistas, mantener elementos persistentes y hacer que el recorrido pareciera más fluido. El problema es que muchas veces esto implicaba añadir frameworks, routers, estados compartidos y lógica adicional solo para conseguir una transición más amable.
Aquí es donde las transiciones entre páginas CSS cobran valor. Con la View Transitions API, un sitio multipágina puede sentirse más fluido sin convertirse necesariamente en una SPA. Esto es especialmente interesante para proyectos como blogs técnicos, portfolios, documentación, landings o webs corporativas donde no siempre tiene sentido cargar un framework completo solo para animar la navegación.
Además, una buena transición puede mejorar la percepción de rendimiento. No significa que la página cargue mágicamente más rápido, pero sí puede hacer que el cambio resulte menos brusco y más comprensible. Cuando el usuario mantiene una referencia visual —por ejemplo, una imagen que se transforma desde una tarjeta hacia una cabecera de detalle— entiende mejor la relación entre origen y destino.
Continuidad visual y carga cognitiva
Una interfaz no solo debe funcionar: también debe explicar visualmente lo que está ocurriendo. Cuando todo cambia de golpe, el usuario necesita reconstruir el contexto. Tiene que identificar dónde está, qué elemento ha cambiado y cómo volver atrás si lo necesita.
Las transiciones bien diseñadas reducen esa carga cognitiva. No porque añadan “efectos bonitos”, sino porque ayudan a conectar dos estados de la interfaz. Una tarjeta que se expande, una imagen que conserva su posición relativa o un contenido que entra suavemente desde una dirección coherente son recursos visuales que guían la atención.
Eso sí, conviene recordar algo importante: una transición debe estar al servicio de la experiencia. Si ralentiza demasiado la navegación, distrae o se repite de forma excesiva, deja de ayudar. La View Transitions API CSS es potente, pero sigue necesitando criterio de diseño.
Cómo funciona una view transition en el navegador
Para entender la API, podemos imaginar el proceso en tres momentos:
- El navegador captura el estado visual actual.
- Se produce el cambio de contenido o navegación.
- El navegador captura el nuevo estado y anima la transición entre ambos.
Por defecto, si no personalizamos nada, el navegador puede aplicar una transición tipo fundido entre la vista anterior y la nueva. A partir de ahí, podemos intervenir con CSS mediante pseudo-elementos específicos como:
::view-transition-old(root)
::view-transition-new(root)
::view-transition-group(root)
Estos pseudo-elementos representan las capturas de la vista antigua y la vista nueva. Gracias a ellos podemos definir animaciones personalizadas, ajustar duraciones, aplicar transformaciones y controlar cómo aparece o desaparece cada estado.
La palabra root hace referencia a la transición principal de la página. Si queremos animar elementos concretos de forma independiente, podemos asignarles un nombre con view-transition-name.
.card-image {
view-transition-name: featured-image;
}
Con esto le indicamos al navegador que ese elemento debe participar en una transición propia, separada de la transición general de la página. Es uno de los puntos más interesantes de la API, porque permite crear efectos tipo “elemento compartido” entre una página de listado y una página de detalle.
El papel de view-transition-name
La propiedad view-transition-name permite identificar elementos que queremos animar de manera específica durante una transición. Por ejemplo, imagina una página de artículos donde cada tarjeta tiene una imagen destacada. Al hacer clic en una tarjeta, esa imagen podría transformarse suavemente en la imagen principal del post.
.post-card__image {
view-transition-name: post-image;
}
.post-header__image {
view-transition-name: post-image;
}
Para que esto funcione correctamente, el nombre debe ser coherente entre el estado anterior y el nuevo. La API puede relacionar ambos elementos y generar una transición más natural.
Sin embargo, hay una regla importante: no conviene repetir el mismo view-transition-name en varios elementos visibles al mismo tiempo. Si varias piezas comparten el mismo identificador en el mismo estado, el navegador no puede saber cuál debe asociar con cuál. Por eso, en listados dinámicos, suele ser necesario generar nombres únicos.
.card-article-1 {
view-transition-name: article-1;
}
.card-article-2 {
view-transition-name: article-2;
}
En proyectos reales, esos nombres suelen generarse a partir de un identificador del contenido, como el slug de un artículo o el ID de un producto.
View Transitions API en SPA: animaciones SPA CSS con JavaScript mínimo
En una SPA, el cambio de vista ocurre dentro del mismo documento. No hay una navegación tradicional a otro HTML, sino una actualización del DOM. Para estos casos se utiliza document.startViewTransition().
Un ejemplo básico podría ser este:
function updateView() {
const container = document.querySelector(".content");
container.innerHTML = `
<article>
<h2>Nueva vista</h2>
<p>Contenido actualizado con una transición suave.</p>
</article>
`;
}
if (document.startViewTransition) {
document.startViewTransition(() => updateView());
} else {
updateView();
}
Aquí hay dos ideas importantes. La primera es que el cambio del DOM se ejecuta dentro de la función que pasamos a startViewTransition(). La segunda es que añadimos una condición para comprobar si el navegador soporta la API. Si no la soporta, simplemente actualizamos la vista sin transición.
Este enfoque es muy útil para crear animaciones SPA CSS sin depender de librerías externas. Puedes integrarlo en una aplicación con React, Vue, Svelte, Astro con islands, JavaScript vanilla o cualquier arquitectura donde el contenido cambie sin recargar todo el documento.
Personalizar la transición con CSS
Una vez activada la transición, podemos definir cómo se animan la vista antigua y la nueva:
::view-transition-old(root) {
animation: fade-out 0.25s ease both;
}
::view-transition-new(root) {
animation: fade-in 0.35s ease both;
}
@keyframes fade-out {
from {
opacity: 1;
}
to {
opacity: 0;
}
}
@keyframes fade-in {
from {
opacity: 0;
transform: translateY(12px);
}
to {
opacity: 1;
transform: translateY(0);
}
}
Este ejemplo combina opacity y transform, dos propiedades recomendables cuando buscamos animaciones fluidas. En general, es mejor evitar animar propiedades como width, height, top o left si no es necesario, porque pueden provocar recálculos de layout y afectar al rendimiento.
La View Transitions API no elimina las buenas prácticas de animación CSS: las hace todavía más importantes.
View Transitions API en MPA: transiciones entre páginas reales
Una de las partes más atractivas de esta API es su capacidad para trabajar con sitios multipágina. Es decir, webs donde cada URL carga un documento diferente. En estos casos, no llamamos a document.startViewTransition() manualmente. En su lugar, activamos las transiciones desde CSS con la regla @view-transition.
@view-transition {
navigation: auto;
}
Esta regla debe estar presente en las páginas que participan en la navegación. Por ejemplo, si quieres animar el paso entre /blog/ y /blog/view-transitions-api/, ambas páginas deberían incluir esta regla en su CSS.
A partir de ahí, el navegador puede aplicar una transición cuando el usuario navega entre documentos del mismo origen. Esto resulta muy interesante para sitios creados con Astro, Eleventy, WordPress, HTML estático o cualquier arquitectura multipágina.
Ejemplo de transición entre páginas
Podemos empezar con una animación general para toda la página:
@view-transition {
navigation: auto;
}
::view-transition-old(root) {
animation: page-out 0.3s ease both;
}
::view-transition-new(root) {
animation: page-in 0.35s ease both;
}
@keyframes page-out {
from {
opacity: 1;
transform: translateY(0);
}
to {
opacity: 0;
transform: translateY(-16px);
}
}
@keyframes page-in {
from {
opacity: 0;
transform: translateY(16px);
}
to {
opacity: 1;
transform: translateY(0);
}
}
Con muy poco código, un sitio multipágina puede ganar una sensación de continuidad mucho mayor. El cambio sigue siendo una navegación real, pero visualmente se percibe más suave.
Limitaciones importantes en navegación multipágina
Aunque esta API abre muchas posibilidades, no conviene aplicarla sin entender sus límites. En transiciones entre documentos, las páginas deben pertenecer al mismo origen. Además, la navegación tiene que cumplir ciertas condiciones para que el navegador pueda coordinar la transición.
También hay que tener en cuenta que la API es progresiva. Si no está disponible en un navegador concreto, la web debe seguir funcionando perfectamente. Esto es una ventaja: podemos diseñar la experiencia base sin animación y añadir la transición como mejora progresiva.
@media (prefers-reduced-motion: reduce) {
::view-transition-old(root),
::view-transition-new(root) {
animation: none;
}
}
Respetar prefers-reduced-motion es fundamental. Algunas personas prefieren reducir las animaciones por comodidad, accesibilidad o sensibilidad al movimiento. Una transición entre páginas no debería imponerse a toda costa.
Diferencias entre animaciones tradicionales y View Transitions API CSS
Las animaciones tradicionales con CSS funcionan muy bien cuando queremos animar un elemento que ya existe en pantalla: un botón, un menú, una tarjeta, un tooltip o un loader. Podemos usar transition, @keyframes, transform, opacity y muchas otras propiedades.
La View Transitions API CSS, en cambio, se centra en animar el cambio entre dos estados de la interfaz. No anima únicamente un elemento aislado, sino la relación visual entre una vista anterior y una vista nueva.
La diferencia es sutil, pero importante:
- Una transición CSS tradicional anima un cambio de propiedad.
- Una view transition anima un cambio de vista.
- Una SPA puede usarla para cambios internos de contenido.
- Una MPA puede usarla para suavizar navegaciones reales entre páginas.
Esto no significa que una opción sustituya a la otra. De hecho, lo habitual será combinarlas. Puedes seguir usando transition para microinteracciones y reservar la View Transitions API para cambios de vista más estructurales.
Buenas prácticas para usar view transition en proyectos reales
Antes de añadir transiciones entre páginas a todo un sitio, conviene definir una pequeña estrategia. Animar cada navegación de forma diferente puede parecer atractivo al principio, pero también puede crear una experiencia confusa.
Mantén las animaciones breves
Una transición entre páginas debería ser rápida. Como referencia general, duraciones entre 200 y 400 milisegundos suelen funcionar bien para cambios frecuentes. Si la animación dura demasiado, el usuario puede sentir que la interfaz va lenta.
::view-transition-group(root) {
animation-duration: 0.3s;
}
La animación debe acompañar, no bloquear.
Usa movimiento con intención
No todos los cambios necesitan desplazamientos grandes. A veces, un simple fundido con una ligera traslación es suficiente. Si un contenido entra desde la derecha, por ejemplo, debería haber una lógica espacial detrás: avance, detalle, navegación lateral, siguiente paso, etc.
El movimiento comunica jerarquía. Por eso, una transición mal planteada puede confundir más de lo que ayuda.
Evita animar demasiados elementos a la vez
La API permite animar elementos concretos con view-transition-name, pero eso no significa que debas nombrarlo todo. Si cada imagen, título, botón y bloque de texto intenta tener una transición propia, el resultado puede parecer caótico.
Lo más efectivo suele ser elegir uno o dos elementos protagonistas:
.article-card__image {
view-transition-name: article-image;
}
.article-title {
view-transition-name: article-title;
}
Una imagen destacada y un título pueden ser suficientes para conectar visualmente una tarjeta con su página de detalle.
Diseña siempre una experiencia sin animación
La mejora progresiva debe ser la base. Tu sitio debe poder navegarse, leerse y utilizarse aunque la View Transitions API no esté disponible. Esto implica no depender de la animación para mostrar información esencial.
Una buena práctica es construir primero la experiencia normal y después añadir la transición encima. Así evitas que la interfaz dependa de una característica concreta del navegador.
Casos de uso recomendados
La View Transitions API encaja especialmente bien en interfaces donde existe una relación clara entre dos vistas.
Listado y detalle
Es uno de los casos más naturales. Un usuario hace clic en una tarjeta de un listado y llega a una página de detalle. Si la imagen, el título o una etiqueta se mantienen como referencia visual, la transición ayuda a entender que el contenido se ha expandido.
Esto puede aplicarse a blogs, portfolios, catálogos, recetas, cursos, documentación o productos.
Cambio de tema visual
Otro caso interesante es el cambio entre modo claro y oscuro. En lugar de alternar los colores de golpe, podemos envolver el cambio de clase dentro de startViewTransition().
const button = document.querySelector(".theme-toggle");
button.addEventListener("click", () => {
const changeTheme = () => {
document.documentElement.classList.toggle("dark");
};
if (document.startViewTransition) {
document.startViewTransition(changeTheme);
} else {
changeTheme();
}
});
Con CSS, después podemos suavizar el cambio visual. Eso sí, conviene no exagerar: en un cambio de tema, la transición debe ser elegante y rápida.
Galerías y filtros
Cuando una galería cambia de orden, aplica filtros o muestra nuevos elementos, una view transition puede hacer que el cambio resulte más comprensible. En lugar de que los elementos salten bruscamente de lugar, el usuario percibe una reorganización más natural.
En estos casos, la propiedad view-transition-name puede ser especialmente útil si cada elemento tiene un identificador único.
Errores comunes al trabajar con View Transitions API
Uno de los errores más habituales es pensar que esta API convierte cualquier animación en “automática”. No es así. El navegador facilita la captura y la transición, pero el diseño de la animación sigue dependiendo de nosotras.
Otro error común es usar la API para maquillar problemas de rendimiento. Si una página carga lenta, tiene imágenes pesadas o bloquea el hilo principal con JavaScript, una transición puede suavizar la percepción, pero no soluciona el problema de fondo.
También conviene evitar transiciones demasiado protagonistas. Una navegación no debería convertirse en un espectáculo visual cada vez que el usuario hace clic. En interfaces de uso frecuente, la repetición excesiva puede cansar.
Por último, es importante probar en dispositivos reales. Una animación que se ve perfecta en un equipo potente puede sentirse menos fluida en un móvil con menos recursos. La experiencia debe evaluarse en condiciones realistas.
SEO y experiencia de usuario: por qué esta API también importa
Desde el punto de vista SEO, la View Transitions API no posiciona por sí sola. Google no va a premiar una página únicamente porque tenga animaciones entre vistas. Sin embargo, sí puede influir indirectamente en la experiencia de usuario.
Una navegación más agradable puede ayudar a que el usuario explore más contenido, entienda mejor la arquitectura del sitio y perciba la web como más cuidada. En un blog técnico, por ejemplo, una transición sutil entre el listado de artículos y la página de detalle puede reforzar la sensación de continuidad sin sacrificar rendimiento ni accesibilidad.
Además, al poder aplicarse en sitios multipágina, esta API permite conservar ventajas tradicionales de arquitectura web —URLs claras, HTML renderizado, navegación estándar— mientras se añade una capa de interacción más moderna.
La clave está en no confundir animación con valor. Una transición bien pensada mejora la experiencia. Una transición innecesaria solo añade ruido.
Ejemplo completo básico
Este sería un ejemplo mínimo para una web multipágina:
@view-transition {
navigation: auto;
}
::view-transition-old(root) {
animation: exit-page 0.25s ease both;
}
::view-transition-new(root) {
animation: enter-page 0.35s ease both;
}
@keyframes exit-page {
from {
opacity: 1;
transform: scale(1);
}
to {
opacity: 0;
transform: scale(0.98);
}
}
@keyframes enter-page {
from {
opacity: 0;
transform: scale(1.02);
}
to {
opacity: 1;
transform: scale(1);
}
}
@media (prefers-reduced-motion: reduce) {
::view-transition-old(root),
::view-transition-new(root) {
animation: none;
}
}
Este código activa la transición, define una salida suave, una entrada ligera y respeta las preferencias de movimiento reducido. Es una base sencilla, pero suficiente para empezar a experimentar.
Preguntas frecuentes sobre View Transitions API
¿La View Transitions API sustituye a las animaciones CSS tradicionales?
No. La View Transitions API no sustituye a transition, animation o @keyframes. Más bien, los complementa. Las animaciones CSS tradicionales siguen siendo ideales para microinteracciones, botones, menús, loaders o estados hover. La View Transitions API está pensada para animar cambios de vista más amplios, como una navegación entre páginas o una actualización importante del DOM.
¿Puedo usar View Transitions API en una web hecha con WordPress o Astro?
Sí, especialmente en sitios multipágina donde puedas añadir CSS global. Para transiciones entre páginas reales, la regla @view-transition { navigation: auto; } puede ser una forma sencilla de empezar. En proyectos con Astro, WordPress, Eleventy o HTML estático, esta API resulta muy interesante porque permite conseguir una sensación más fluida sin convertir toda la web en una SPA.
¿Es recomendable usar view transition en todas las páginas?
No necesariamente. Lo ideal es usarla donde aporte claridad y continuidad. Por ejemplo, entre un listado y una página de detalle, entre secciones relacionadas o en cambios de estado visual importantes. Si se aplica de forma indiscriminada, puede terminar siendo repetitiva o molesta. Como casi siempre en diseño de interacción, menos puede ser más.
Reflexión final: animar para orientar, no para decorar
La View Transitions API representa un paso muy interesante en la evolución de las animaciones web. Durante años, crear transiciones fluidas entre páginas requería soluciones complejas, dependencias externas o arquitecturas SPA que no siempre eran necesarias. Ahora, el navegador empieza a ofrecernos herramientas más nativas para resolver ese problema con menos fricción.
Pero la verdadera potencia de esta API no está en hacer que todo se mueva. Está en permitir que el movimiento tenga sentido. Una buena transición ayuda al usuario a mantener el contexto, comprender la relación entre dos vistas y sentir que la interfaz responde de forma cuidada.
Por eso, al trabajar con View Transitions API CSS, conviene hacerse una pregunta antes de escribir código: ¿esta animación ayuda a entender mejor la experiencia o solo añade efecto visual? Si la respuesta es la primera, probablemente estás ante un buen caso de uso.
Las mejores animaciones web no son las más llamativas, sino las que hacen que la navegación parezca natural. Y ahí es donde esta API puede convertirse en una herramienta muy valiosa para crear interfaces modernas, fluidas y más humanas.
