L'impact des transitions de vue CSS sur la performance web

L'impact de l'API View Transition sur la performance

L'API View Transition permet aux développeurs d'activer des transitions visuelles fluides entre les aperçus sur le même site, même pour les applications multi-pages (MPA). Ces transitions de vue sont gérées par des transitions CSS entre 2 vues de page. Historiquement, les transitions CSS pendant le chargement de la page causent un retard dans les métriques LCP. Nous soupçonnions que ces types de transitions de vue inter-pages avaient également des implications sur la performance, en particulier sur les appareils mobiles et les processeurs plus lents. Nos recherches et nos données de Real-User Monitoring (RUM) ont confirmé ces soupçons ainsi que d'autres informations intéressantes sur son effet sur les Core Web Vitals, en particulier le Largest Contentful Paint (LCP).

>

Résultats des données RUM

Pour valider notre idée selon laquelle la transition de vue impacte 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 autres 50% des pages vues étaient servies sans ces styles.

Nous avons collecté plus de 500 000 pages vues, dont 120 000 pages vues sur mobile 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 l'API View Transition ajoute environ 70 ms au Largest Contentful Paint pour les pages vues répétées sur mobile. Cette augmentation du temps LCP est notable, considérant 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 expérience utilisateur.

Corrélation avec la performance CPU

Ayant confirmé l'impact négatif des transitions de vue sur le LCP, nous avons poussé l'enquête plus loin. Nous avons procédé à la mise en place d'une série d'expériences pour tester automatiquement les 2 mêmes pages avec et sans transitions de vue. Les résultats montrent une corrélation claire entre la vitesse du CPU et l'impact des transitions de vue 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 transitions de vue

Configuration	Avec View Transition	Sans View Transition	Différence (ms)
Sans limitation + mise en cache réseau	287 ms	282 ms	5 ms
Sans limitation + sans mise en cache réseau	338 ms	311 ms	37 ms
Ralentissement CPU 6x + mise en cache réseau	527 ms	523 ms	4 ms
Ralentissement CPU 6x + sans mise en cache réseau	442 ms	413 ms	29 ms
Ralentissement CPU 20x + mise en cache réseau	756 ms	716 ms	40 ms
Ralentissement CPU 20x + sans mise en cache réseau	1281 ms	1204 ms	77 ms

Si vous souhaitez tester cela par vous-même, visitez notre [url=https://corewebvitals.github.io/view-transition/]page d'accueil de l'expérience de transition de vue[/url] sur github

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

• Les transitions de vue ralentissent le LCP : Les pages vues avec des transitions de vue sont plus lentes que les pages vues sans effets de transition de vue.
• La vitesse du CPU est un facteur important : La vitesse du CPU a une forte corrélation avec la différence de LCP dans les vues avec et sans effets de transition de page
• Il y a un 'point idéal' de vitesse de page : À un ralentissement de 6x, le LCP a une meilleure performance 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 mise en cache réseau et la transition est appliquée à une page blanche. Immédiatement après la transition plus simple vers une page blanche, l'élément LCP est peint. Apparemment, c'est le point idéal où il est plus efficace de faire une transition vers une page blanche que de faire une transition entre des images. D'un point de vue UX, il est bien sûr préférable de faire une transition entre des images.

Comprendre view-transition: navigation: auto;

Traditionnellement, l'implémentation des transitions de vue nécessitait une utilisation extensive de CSS et JavaScript. L'API View Transition simplifie ce processus en permettant aux développeurs de définir des transitions de manière déclarative. L'API View transition 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 de base de la façon d'utiliser view-transition-name: auto dans votre CSS :

@view-transition {
  navigation: auto;
}

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

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

Ce simple ajout permet au navigateur de gérer la transition de cet élément automatiquement lorsqu'une transition de vue se produit.

Équilibrer esthétique et performance

L'API View Transition offre des transitions fluides et potentiellement visuellement agréables entre les navigations. Cela pourrait conduire à de petits avantages dans les métriques commerciales comme des taux de rebond plus bas et potentiellement des ventes plus élevées. Cependant, en particulier sur les navigateurs bas de gamme comme les appareils mobiles, les développeurs doivent soigneusement considérer ses implications sur la performance. Voici mes recommandations :

• Tests de performance : Menez des tests approfondis sur divers appareils et conditions réseau pour vous assurer que les avantages des transitions de vue l'emportent sur les coûts potentiels de performance.
• Implémentation sélective : Soyez prudent lors de l'application des transitions de vue. Testez son effet sur la performance et les métriques commerciales. Ensuite, considérez soigneusement sur quels types d'appareils implémenter les transitions de vue.