El impacto de las CSS View Transitions en el rendimiento web

El impacto de la View Transition API en el rendimiento

La View Transition API permite a los desarrolladores habilitar transiciones visuales fluidas entre vistas en el mismo sitio, incluso para aplicaciones multipágina (MPAs). Estas view transitions se gestionan mediante transiciones CSS entre dos vistas de página. Históricamente, las transiciones CSS durante la carga de la página provocan un retraso en la métrica LCP. Sospechábamos que estas view transitions entre páginas también tenían implicaciones de rendimiento, especialmente en dispositivos móviles y CPUs más lentas. Nuestros datos de Real User Monitoring (RUM) confirmaron estas sospechas, junto con otras conclusiones interesantes sobre el efecto en Core Web Vitals, especialmente el Largest Contentful Paint (LCP).

Última revisión por Arjen Karel en febrero de 2026

Hallazgos de los datos RUM

Para validar nuestra idea de que las view transitions afectan negativamente al Largest Contentful Paint, configuramos una serie de tests A/B en 5 sitios diferentes y los dejamos funcionando durante 7 días. En el 50% de las páginas vistas añadimos @view-transition { navigation: auto;} a las hojas de estilo de la página, mientras que el otro 50% de las páginas vistas se sirvió sin estos estilos.

Recopilamos más de 500.000 páginas vistas, de las cuales se analizaron finalmente 120.000 páginas vistas móviles porque procedían de navegaciones móviles dentro del mismo sitio.

Los datos de Real User Monitoring han revelado que implementar la View Transition API añade aproximadamente 70ms al Largest Contentful Paint en páginas vistas móviles repetidas. Este incremento en el tiempo de LCP es significativo, considerando que Google recomienda que el LCP debería ocurrir dentro de los 2,5 segundos desde que la página comienza a cargarse para una buena user experience.

Correlación con el rendimiento de la CPU

Tras confirmar el impacto negativo de las view transitions en el LCP, investigamos más a fondo. Procedimos a configurar una serie de experimentos para probar automáticamente las mismas 2 páginas con y sin view transitions. Los resultados muestran una clara correlación entre la velocidad de la CPU y el impacto de las view transitions en el LCP. Los hallazgos indican que cuanto más lenta es la CPU, más pronunciado es el efecto negativo en el LCP al usar view transitions.

Si quieres probarlo por ti mismo, visita nuestra página del experimento de view transition en GitHub.

Estos resultados destacan tres observaciones clave:

• Las view transitions ralentizan el LCP: Las páginas vistas con view transitions son más lentas que las páginas vistas sin efectos de view transition.
• La velocidad de la CPU es un factor importante: La velocidad de la CPU tiene una alta correlación con la diferencia de LCP en vistas con y sin efectos de transición de página. Esto importa especialmente para dispositivos móviles de gama baja.
• Existe un 'punto óptimo' de velocidad de página: Con una ralentización de 6x, el LCP tiene mejor rendimiento sin caché de red. La razón simple es que a esta velocidad de CPU el elemento LCP aún no se ha decodificado sin caché de red y la transición se aplica a una página en blanco. Inmediatamente después de la transición más simple a una página en blanco, el elemento LCP se pinta. Aparentemente, este es el punto óptimo donde es más eficiente hacer la transición a una página en blanco que hacer la transición entre imágenes. Desde una perspectiva de UX, es mejor hacer la transición entre imágenes, por supuesto.

Compatibilidad con navegadores

La View Transition API alcanzó el estado Baseline Newly Available en octubre de 2025. Las view transitions del mismo documento ahora funcionan en Chrome 111+, Edge 111+, Firefox 144+ y Safari 18+, cubriendo aproximadamente el 89% del tráfico global de navegadores. Las view transitions entre documentos (las activadas por @view-transition { navigation: auto; }) tienen un soporte ligeramente más reducido pero funcionan en todos los navegadores principales excepto en versiones antiguas de Firefox.

Este amplio soporte significa que más desarrolladores adoptarán las view transitions, haciendo que las implicaciones de rendimiento sean aún más relevantes.

Entendiendo @view-transition { navigation: auto; }

Tradicionalmente, implementar view transitions requería un uso extensivo de CSS y JavaScript. La View Transition API simplifica este proceso al permitir a los desarrolladores definir transiciones de forma declarativa. La View Transition API funciona capturando instantáneas de los estados antiguo y nuevo de un documento, actualizando el DOM mientras suprime el renderizado, y utilizando animaciones CSS para ejecutar la transición.

Ejemplo de implementación

Aquí tienes un ejemplo básico de cómo habilitar view transitions entre documentos en tu CSS:

@view-transition {
  navigation: auto;
}

O en combinación con una media query para apuntar a dispositivos de tablet o escritorio:

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

Esta simple adición permite al navegador gestionar la transición automáticamente al navegar entre páginas del mismo origen.

Accesibilidad: prefers-reduced-motion

Los usuarios que prefieren movimiento reducido no deberían verse obligados a pasar por animaciones. Envuelve tu regla de view transition en una media query prefers-reduced-motion. Esto también elimina la penalización de LCP para esos usuarios.

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

Eliminando el coste de LCP con Speculation Rules

La mejor forma de usar view transitions sin la penalización de LCP es combinarlas con la Speculation Rules API. Cuando el navegador prerenderiza la siguiente página antes de que el usuario haga clic, la view transition se anima entre dos estados ya renderizados. El elemento LCP ya está cargado y decodificado, por lo que la transición no añade ningún retraso medible. Si te importan tanto la estética como el rendimiento, esta es la combinación que debes usar.

Recomendaciones

La View Transition API ofrece transiciones fluidas y visualmente agradables entre navegaciones. Esto puede llevar a pequeños beneficios en métricas de negocio como tasas de rebote más bajas y mayor engagement. Sin embargo, especialmente en dispositivos móviles de gama baja, los desarrolladores deben considerar cuidadosamente las implicaciones de rendimiento. Estas son mis recomendaciones:

• Comprueba primero tu presupuesto de LCP. Si tu LCP móvil ya está por encima de 2,0 segundos, añadir 70ms de sobrecarga de transición te acerca más al fallo. Corrige primero el LCP, añade las transiciones después.
• Combina con Speculation Rules. Prerenderizar la página de destino elimina por completo el coste de LCP de las view transitions.
• Usa prefers-reduced-motion. Envolver las view transitions en una media query de movimiento reducido respeta las preferencias del usuario y elimina el coste de rendimiento para los usuarios que no quieren animaciones.
• Prueba con usuarios reales. Los tests de laboratorio no capturan la gama completa de dispositivos y condiciones de red que usan tus visitantes. Ejecuta un test A/B con CoreDash para medir el impacto real en tu LCP antes y después de habilitar las view transitions.
• Considera solo escritorio. Nuestros datos muestran que los dispositivos de escritorio con CPUs rápidas experimentan casi ningún impacto en el LCP (5ms). Restringir las view transitions al escritorio mediante una media query min-width es un compromiso razonable.