View Transitions entre páginas: lo que ya sirve y lo que todavía te hace perder tiempo
Las transiciones entre páginas habían vivido mucho tiempo en territorio de frameworks, routers client-side y demos medio tramposas. Si querías que un sitio se sintiera fluido al pasar de una vista a otra, casi siempre terminabas empujando una SPA, aunque el proyecto no la necesitara.
Eso empezó a cambiar con cross-document view transitions.
La idea es simple: permitir que una navegación normal entre dos páginas del mismo sitio tenga una transición visual nativa, sin convertir todo tu proyecto en una aplicación de una sola página. O sea, seguir trabajando con HTML real, links reales y navegación real, pero con una capa de continuidad visual mucho más cuidada.
Y sí, esto sirve. Sobre todo en sitios editoriales, catálogos, portafolios y cualquier experiencia donde el salto entre una página y otra se siente brusco.
El detalle es que también es una de esas features que parece más fácil de lo que realmente es. Se activa rápido, pero si no entiendes bien qué hace, cuándo aplica y por qué falla, terminas pensando que el navegador te está trolleando.
Qué son las cross-document view transitions
Hay dos familias que suelen meterse en la misma conversación y eso confunde bastante.
La primera son las same-document view transitions. Ésas pasan dentro del mismo documento. Son comunes en SPAs o en interfaces donde cambias partes del DOM sin salir de la página. Ahí entra document.startViewTransition() y el control vive más del lado de JavaScript.
La segunda es la que nos interesa aquí: cross-document view transitions. Ésas corren entre una página y otra. Sales de un documento, entras a otro y el navegador intenta animar ese cambio de forma más suave.
La diferencia importa porque el modelo mental cambia por completo.
En una SPA tú controlas más cosas: cuándo cambia el DOM, qué elementos permanecen, cómo nombras ciertas partes. En una navegación entre páginas normales, el browser hace bastante trabajo por ti, pero también pone condiciones. Si esas condiciones no se cumplen, la transición simplemente no ocurre.
Para qué sirven de verdad
No las metería en cualquier proyecto solo porque se ven bonitas en una demo.
Sirven cuando la navegación tiene continuidad visual real. Cuando el usuario siente que está entrando a una versión más detallada, relacionada o ampliada de lo que ya estaba viendo.
Caso de uso 1: de un listado de artículos al artículo completo
Este es el caso más natural para un sitio como CSS-Tianguis.
Piensa en una portada con varias tarjetas de posts. El usuario entra a una nota, lee, y luego vuelve al índice. Normalmente ese cambio es seco: clic, recarga, página nueva. Funciona, sí, pero no hay continuidad.
Con una transición bien aplicada, el cambio se siente más cohesivo. No vuelve mágicamente mejor el contenido, pero sí hace que el sitio se perciba más cuidado. En un medio editorial eso pesa más de lo que parece.
Además, este caso tiene otra ventaja: no necesitas inventar una arquitectura rara. Sigues con páginas reales, enlaces normales y una experiencia más refinada.
Caso de uso 2: de una card de producto o proyecto a la vista de detalle
Aquí el beneficio visual se nota todavía más.
Si tienes un grid de productos, inmuebles, proyectos o trabajos de portafolio, la transición ayuda a que el usuario entienda que no “saltó” a otro universo, sino que abrió el detalle de algo que ya venía viendo.
Cuando una imagen, título o bloque visual conserva cierta continuidad entre ambas páginas, la experiencia se siente más estable. Menos abrupta. Más intencional.
Eso sí: este tipo de caso también expone más fácil los errores. Si algo no coincide bien entre una vista y otra, el fallo se ve de inmediato.
Cómo se activan hoy
La forma actual de habilitarlas en una navegación básica es con la regla @view-transition en CSS.
@view-transition {
navigation: auto;
}Eso le dice al navegador que intente aplicar transiciones automáticas en navegaciones normales del mismo origen.
Lo importante aquí es que esto debe existir en las páginas involucradas. Si una página participa y la otra no, no esperes milagros.
Una ventaja de que viva en CSS es que puedes condicionarlo sin drama.
Por ejemplo, si quieres respetar prefers-reduced-motion:
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}O si quieres limitarlo a ciertos tamaños de pantalla:
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
}Eso ya la vuelve una herramienta más seria y menos feature de demo.
Un ejemplo mínimo entre dos páginas
Supón que tienes un listado de artículos y una página individual. La base puede ser tan simple como esto.
index.html
<!doctype html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>CSS-Tianguis</title>
<link rel="stylesheet" href="/styles.css" />
</head>
<body>
<main class="post-list">
<a class="post-card" href="/post.html">
<img src="/img/view-transitions-cover.jpg" alt="Portada del artículo" />
<h2>View Transitions entre páginas</h2>
Qué son, para qué sirven y por qué a veces fallan.
</a>
</main>
</body>
</html>post.html
<!doctype html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>View Transitions entre páginas</title>
<link rel="stylesheet" href="/styles.css" />
</head>
<body>
<article class="post">
<a href="/index.html">← Volver</a>
<h1>View Transitions entre páginas</h1>
Ya no necesitas volver SPA todo para suavizar una navegación.
</article>
</body>
</html>styles.css
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
body {
font-family: system-ui, sans-serif;
margin: 0;
background: #0f172a;
color: white;
}
.post-list,
.post {
width: min(920px, calc(100% - 32px));
margin: 40px auto;
}
.post-card {
display: block;
padding: 24px;
border-radius: 20px;
background: #1e293b;
color: inherit;
text-decoration: none;
}Con eso ya puedes obtener una transición básica en navegaciones compatibles. Sin JavaScript. Sin router. Sin meter una capa extra de complejidad porque sí.
Un segundo ejemplo con elemento compartido
Si quieres una transición más interesante, puedes empatar una imagen y un título entre el listado y el detalle.
Listado
<a class="case-card" href="/proyecto/casa-oasis.html">
<img class="case-card__image" src="/img/casa-oasis.jpg" alt="Proyecto Casa Oasis" />
<h2 class="case-card__title">Casa Oasis</h2>
</a>Detalle
<article class="case-detail">
<img class="case-detail__image" src="/img/casa-oasis.jpg" alt="Proyecto Casa Oasis" />
<h1 class="case-detail__title">Casa Oasis</h1>
Una landing enfocada en velocidad, recorrido visual y contacto directo.
</article>CSS compartido
.case-card__image,
.case-detail__image {
view-transition-name: proyecto-imagen;
}
.case-card__title,
.case-detail__title {
view-transition-name: proyecto-titulo;
}Aquí ya hay una continuidad más clara. El navegador intenta relacionar esas piezas entre ambas páginas y el cambio se siente menos seco.
La clave es no querer empatar media interfaz. Una imagen y un título suelen ser suficiente para que el efecto se sienta intencional.
Dónde se nota más el beneficio
La diferencia no está solo en “se ve bonito”.
Se nota en tres cosas concretas:
- la navegación se siente menos brusca
- el sitio transmite más intención visual
- el usuario entiende mejor la relación entre una vista y la siguiente
Esto es importante porque muchas animaciones web sobran. Estorban más de lo que ayudan. Las view transitions valen la pena cuando refuerzan continuidad, no cuando convierten cada clic en un show.
Si tu página es una calculadora interna o un admin sin ninguna capa visual que cuidar, probablemente no pasa nada si no las usas. Pero en un proyecto con contenido, catálogo, storytelling o branding, sí pueden sumar.
Por qué normalmente fallan
Aquí es donde mucha gente se atora.
No porque la idea sea mala, sino porque hay varias condiciones que deben alinearse y casi nadie las explica completas.
1. Estás siguiendo una guía vieja
Durante un tiempo hubo ejemplos con un meta tag que ya no representa la forma actual de trabajar esto.
Si sigues copiando snippets viejos, puedes pasar un buen rato preguntándote por qué no pasa nada. Y el navegador ni siquiera siempre te lo va a gritar en la cara.
Hoy la referencia buena es @view-transition en CSS.
2. Estás mezclando same-document con cross-document
Éste es un clásico.
Ves un tutorial con document.startViewTransition(), lo pruebas en tu sitio multipágina y descubres que no resuelve el caso que querías.
No porque la API esté mal, sino porque pertenece a otro escenario. Una cosa es animar cambios dentro del mismo documento. Otra es navegar entre dos páginas distintas.
3. Las dos páginas tienen que estar alineadas
Si una página participa y la otra no, la transición no va a comportarse como esperas.
Eso incluye CSS, estructura y condiciones básicas de la navegación. Es una feature entre dos extremos, no una decoración unilateral.
4. La nueva página tarda demasiado en estar lista
Aquí entra un problema menos obvio: rendimiento.
Si la página de destino se tarda demasiado en llegar a un estado renderizable, la transición puede abortarse. Y cuando eso pasa, desde fuera parece que simplemente no funcionó.
Esto suele pasar más en producción que en local. En local todo vuela y piensas que ya quedó. Luego lo subes, metes imágenes pesadas, fuentes, render del lado servidor o alguna dependencia lenta, y la experiencia se cae.
Entonces sí: a veces el fallo no está en la animación. Está en que la página sigue siendo lenta.
5. La navegación no entra en el caso soportado
No toda navegación activa esta capa.
Depende del tipo de salto, del origen, del contexto y de cómo se dispara. Si estás haciendo cosas más complejas, redirecciones raras o flujos no estándar, no des por hecho que el browser lo va a tratar igual que un clic normal entre dos páginas del mismo sitio.
Cómo probarlas sin perder tiempo
Yo probaría en este orden:
- confirmar que ambas páginas tienen
@view-transition - probar con navegación normal entre páginas del mismo dominio
- simplificar el CSS al mínimo posible
- revisar si hay contenido pesado o bloqueos evidentes
- validar en un navegador con soporte actual
Si falla, no empieces metiendo más código. Haz lo contrario. Reduce variables.
Con features nuevas de plataforma, casi siempre conviene volver a una versión mínima primero y luego reconstruir.
Cuándo sí las usaría
Sí las usaría en:
- blogs y medios
- portafolios
- catálogos
- sitios de marca con navegación editorial
- e-commerce con vistas de listado y detalle
No me emocionarían tanto en:
- dashboards internos
- formularios largos
- flujos donde la prioridad es velocidad bruta y cero ornamento
- cualquier interfaz donde la transición no aporta contexto
Porque ese es el punto de fondo: no se trata de animar por animar.
Se trata de hacer que el paso entre una página y otra tenga sentido visual.
Lo que me parece más útil de esta feature
Lo mejor de cross-document view transitions no es que te ahorren JavaScript. Aunque eso ayuda.
Lo mejor es que vuelven a hacer interesante el sitio multipágina bien hecho.
Durante años, demasiadas decisiones de frontend se justificaron con “si quieres una experiencia suave, necesitas una SPA”. Esta feature no elimina esa conversación, pero sí la matiza bastante. Hay casos donde una navegación clásica sigue siendo la mejor opción, y ahora además puede verse mejor sin torcer toda la arquitectura.
Si tu proyecto vive bien como MPA, no deberías empujarlo a otra cosa solo para conseguir una transición decente.
En conclusión
Cross-document view transitions no son magia ni reemplazan criterio de producto. Tampoco arreglan una página lenta, una jerarquía visual floja o una navegación mal pensada.
Pero cuando las usas en el contexto correcto, sí le meten una capa de continuidad muy buena a un sitio normal. Y eso importa.
Yo las tomaría como una herramienta de acabado fino. No como excusa para meter motion por moda, sino como una forma de hacer que ciertas transiciones entre páginas se sientan menos secas y más intencionales.
Si las vas a probar, empieza simple. Un listado y un detalle. Dos páginas limpias. Un caso real. Ahí es donde mejor se entiende si de verdad te aportan o si solo te estaban vendiendo brillo.