L'impact des CSS View Transitions sur les performances web

L'impact de la View Transition API sur les performances

La View Transition API permet aux développeurs d'activer des transitions visuelles fluides entre les vues sur le même site, même pour les applications multipages (MPA). Ces view transitions sont gérées par des transitions CSS entre deux vues de page. Historiquement, les transitions CSS pendant le chargement de la page provoquent un retard dans la métrique LCP. Nous soupçonnions que ces view transitions entre pages avaient également des implications en termes de performance, en particulier sur les appareils mobiles et les CPU plus lents. Nos données de Real User Monitoring (RUM) ont confirmé ces soupçons, ainsi que d'autres observations intéressantes sur l'effet sur les Core Web Vitals, en particulier le Largest Contentful Paint (LCP).

Dernière révision par Arjen Karel en février 2026

Résultats des données RUM

Pour valider notre hypothèse selon laquelle les view transitions impactent négativement le Largest Contentful Paint, nous avons mis en place une série de tests A/B sur 5 sites différents et les avons laissés tourner pendant 7 jours. Sur 50% des pages vues, nous avons ajouté @view-transition { navigation: auto;} aux feuilles de style de la page, tandis que les 50% restants des pages vues étaient servis sans ces styles.

Nous avons collecté plus de 500 000 pages vues, dont 120 000 pages vues mobiles ont finalement été analysées car elles provenaient de navigations mobiles au sein du même site.

Les données de Real User Monitoring ont révélé que l'implémentation de la View Transition API ajoute environ 70ms au Largest Contentful Paint pour les pages vues mobiles répétées. Cette augmentation du temps de LCP est notable, compte tenu de la recommandation de Google selon laquelle le LCP devrait se produire dans les 2,5 secondes suivant le début du chargement de la page pour une bonne user experience.

Corrélation avec les performances du CPU

Après avoir confirmé l'impact négatif des view transitions sur le LCP, nous avons approfondi nos recherches. Nous avons mis en place une série d'expériences pour tester automatiquement les mêmes 2 pages avec et sans view transitions. Les résultats montrent une corrélation claire entre la vitesse du CPU et l'impact des view transitions sur le LCP. Les résultats indiquent que plus le CPU est lent, plus l'effet négatif sur le LCP est prononcé lors de l'utilisation des view transitions.

Si vous souhaitez tester cela par vous-même, visitez notre page d'accueil de l'expérience view transition sur GitHub.

Ces résultats mettent en évidence trois observations clés :

• Les view transitions ralentissent le LCP : Les pages vues avec view transitions sont plus lentes que les pages vues sans effets de view transition.
• La vitesse du CPU est un facteur important : La vitesse du CPU a une forte corrélation avec la différence de LCP entre les vues avec et sans effets de transition de page. Cela est particulièrement important pour les appareils mobiles d'entrée de gamme.
• Il existe un « sweet spot » de vitesse de page : Avec un ralentissement de 6x, le LCP a de meilleures performances sans cache réseau. La raison simple est qu'à cette vitesse de CPU, l'élément LCP n'a pas encore été décodé sans cache réseau et la transition est appliquée à une page vierge. Immédiatement après la transition plus simple vers une page vierge, l'élément LCP est peint. Apparemment, c'est le sweet spot où il est plus efficace de faire la transition vers une page vierge que de faire la transition entre des images. D'un point de vue UX, il est évidemment préférable de faire la transition entre des images.

Support des navigateurs

La View Transition API a atteint le statut Baseline Newly Available en octobre 2025. Les view transitions du même document fonctionnent désormais dans Chrome 111+, Edge 111+, Firefox 144+ et Safari 18+, couvrant environ 89% du trafic mondial des navigateurs. Les view transitions entre documents (celles déclenchées par @view-transition { navigation: auto; }) ont un support légèrement plus restreint mais fonctionnent dans tous les navigateurs principaux sauf les anciennes versions de Firefox.

Ce large support signifie que davantage de développeurs adopteront les view transitions, rendant les implications en termes de performance encore plus pertinentes.

Comprendre @view-transition { navigation: auto; }

Traditionnellement, l'implémentation des view transitions nécessitait une utilisation extensive de CSS et JavaScript. La View Transition API simplifie ce processus en permettant aux développeurs de définir les transitions de manière déclarative. La View Transition API fonctionne en capturant des instantanés des anciens et nouveaux états d'un document, en mettant à jour le DOM tout en supprimant le rendu, et en utilisant des animations CSS pour exécuter la transition.

Exemple d'implémentation

Voici un exemple basique de comment activer les view transitions entre documents dans votre CSS :

@view-transition {
  navigation: auto;
}

Ou en combinaison avec une media query pour cibler les tablettes ou les appareils de bureau :

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

Cet ajout simple permet au navigateur de gérer la transition automatiquement lors de la navigation entre les pages de la même origine.

Accessibilité : prefers-reduced-motion

Les utilisateurs qui préfèrent un mouvement réduit ne devraient pas être contraints de subir des animations. Enveloppez votre règle de view transition dans une media query prefers-reduced-motion. Cela supprime également la pénalité LCP pour ces utilisateurs.

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

Éliminer le coût LCP avec les Speculation Rules

La meilleure façon d'utiliser les view transitions sans la pénalité LCP est de les combiner avec la Speculation Rules API. Lorsque le navigateur précharge la page suivante avant que l'utilisateur ne clique, la view transition s'anime entre deux états déjà rendus. L'élément LCP est déjà chargé et décodé, donc la transition n'ajoute aucun retard mesurable. Si vous vous souciez à la fois de l'esthétique et des performances, c'est la combinaison à utiliser.

Recommandations

La View Transition API offre des transitions fluides et visuellement agréables entre les navigations. Cela peut entraîner de petits bénéfices dans les métriques business comme des taux de rebond plus bas et un engagement plus élevé. Cependant, en particulier sur les appareils mobiles d'entrée de gamme, les développeurs doivent soigneusement considérer les implications en termes de performance. Voici mes recommandations :

• Vérifiez d'abord votre budget LCP. Si votre LCP mobile est déjà au-dessus de 2,0 secondes, ajouter 70ms de surcharge de transition vous rapproche de l'échec. Corrigez d'abord le LCP, ajoutez les transitions ensuite.
• Combinez avec les Speculation Rules. Le prérendu de la page de destination élimine entièrement le coût LCP des view transitions.
• Utilisez prefers-reduced-motion. Envelopper les view transitions dans une media query de mouvement réduit respecte les préférences des utilisateurs et supprime le coût en performance pour les utilisateurs qui ne souhaitent pas d'animations.
• Testez avec de vrais utilisateurs. Les tests en laboratoire ne capturent pas l'ensemble des appareils et des conditions réseau utilisés par vos visiteurs. Lancez un test A/B avec CoreDash pour mesurer l'impact réel sur votre LCP avant et après l'activation des view transitions.
• Envisagez le bureau uniquement. Nos données montrent que les appareils de bureau avec des CPU rapides ne subissent quasiment aucun impact sur le LCP (5ms). Restreindre les view transitions au bureau via une media query min-width est un compromis raisonnable.