El Impacto de las CSS View Transitions en el Rendimiento Web
Comprende por qué y cuándo las view transitions pueden impactar 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 de múltiples páginas (MPA's). Estas view transitions son gestionadas por transiciones CSS entre 2 vistas de página. Históricamente, las transiciones CSS durante la carga de la página causaban un retraso en las métricas de LCP. Sospechábamos que estos tipos de view transitions entre páginas también tienen implicaciones en el rendimiento, particularmente en dispositivos móviles y CPUs más lentas. Nuestra investigación y los datos de real-user monitoring (RUM) han confirmado estas sospechas junto con otros hallazgos interesantes sobre su efecto en Core Web Vitals, especialmente el Largest Contentful Paint (LCP).

Hallazgos de Datos RUM
Para validar nuestra idea de que las view-transition impactan negativamente el Largest Contentful Paint, configuramos una serie de tests A/B en 5 sitios diferentes y los dejamos ejecutarse durante 7 días. En el 50% de las vistas de página añadimos @view-transition { navigation: auto;} a las hojas de estilo de la página, mientras que el otro 50% de las vistas de página se sirvieron sin estos estilos.
Recopilamos más de 500.000 vistas de página donde finalmente se analizaron 120.000 vistas de página móviles porque se originaron a partir 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 para vistas de página móviles repetidas. Este aumento en el tiempo de LCP es notable, considerando la recomendación de Google de que el LCP debe 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
Habiendo confirmado 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
| Configuración | Con View Transition | Sin View Transition | Diferencia (ms) |
|---|---|---|---|
| Sin throttling + caché de red | 287 ms | 282 ms | 5 ms |
| Sin throttling + sin caché de red | 338 ms | 311 ms | 37 ms |
| 6x ralentización de CPU + caché de red | 527 ms | 523 ms | 4 ms |
| 6x ralentización de CPU + sin caché de red | 442 ms | 413 ms | 29 ms |
| 20x ralentización de CPU + caché de red | 756 ms | 716 ms | 40 ms |
| 20x ralentización de CPU + sin caché de red | 1281 ms | 1204 ms | 77 ms |
Si deseas probar esto por ti mismo, visita nuestra página de inicio del experimento de view transition en github
Estos resultados destacan tres observaciones clave:
- Las view transitions ralentizan el LCP: Las vistas de página con view transitions son más lentas que las vistas de página 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
- Existe un 'punto óptimo' de velocidad de página: Con 6x de ralentización, el LCP tiene un 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 transicionar a una página en blanco que transicionar entre imágenes. Desde una perspectiva de UX es mejor transicionar entre imágenes, por supuesto.
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 usar view-transition-name: auto en tu CSS:
@view-transition {
navigation: auto;
} O en combinación con una media query para dirigirse 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 de este elemento automáticamente cuando ocurre una view transition.
Equilibrando Estética y Rendimiento
La View Transition API ofrece transiciones suaves y posiblemente visualmente agradables entre navegaciones. Esto podría generar pequeños beneficios en métricas de negocio como tasas de rebote más bajas y posiblemente mayores ventas. Sin embargo, especialmente en navegadores de gama baja como dispositivos móviles, los desarrolladores deben considerar cuidadosamente sus implicaciones de rendimiento. Estas son mis recomendaciones:
- Pruebas de Rendimiento: Realiza pruebas exhaustivas en diversos dispositivos y condiciones de red para asegurar que los beneficios de las view transitions superen cualquier posible coste de rendimiento.
- Implementación Selectiva: Ten cuidado al aplicar view-transitions. Prueba su efecto en el rendimiento y las métricas de negocio. Luego considera cuidadosamente en qué tipos de dispositivos implementar view transitions.
Make decisions with Data.
You cannot optimize what you do not measure. Install the CoreDash pixel and capture 100% of user experiences.
- 100% Capture
- Data Driven
- Easy Install

