Réponses aux questions fréquentes sur les SPA, les Core Web Vitals et les mesures que Google prévoit de mettre en place pour remédier aux limites actuelles.
Depuis le lancement de l'initiative Web Vitals en mai 2020, l'équipe Chrome a reçu de nombreuses questions et commentaires sur le programme.
Le sujet sur lequel nous avons reçu le plus de questions, et qui est probablement la question la plus difficile à répondre, est la façon de mesurer les métriques Core Web Vitals dans une application monopage (SPA), ainsi que l'impact des architectures SPA sur les scores Core Web Vitals.
Ces questions sont difficiles à répondre, car le problème est assez nuancé. Dans cet article, nous allons donc faire de notre mieux pour répondre aux questions les plus courantes, en fournissant autant de détails et de contexte que possible.
Avant d'entrer dans les détails, il est important de préciser que Google n'a aucune préférence quant à l'architecture ou à la technologie utilisée pour créer un site. Nous pensons que les applications SPA et multipages (MPA) peuvent toutes deux offrir une expérience de haute qualité aux utilisateurs. Notre objectif avec l'initiative Web Vitals est de fournir des métriques qui mesurent l'expérience indépendamment de la technologie. Bien que ce ne soit pas possible dans tous les cas aujourd'hui (en raison des limites de la plate-forme Web), nous travaillons activement à combler ces lacunes.
Questions fréquentes
Les métriques Core Web Vitals incluent-elles les transitions de routes SPA ?
Non. Chacune des métriques Core Web Vitals est mesurée par rapport à la navigation de page de niveau supérieur actuelle. Si une page charge de manière dynamique un nouveau contenu et met à jour l'URL de la page dans la barre d'adresse, cela n'a aucun impact sur la façon dont les métriques Core Web Vitals sont mesurées. Les valeurs des métriques ne sont pas réinitialisées, et l'URL associée à chaque mesure de métrique est l'URL vers laquelle l'utilisateur a accédé pour lancer le chargement de la page.
Les métriques Core Web Vitals peuvent-elles traiter les modifications de route SPA de la même manière que les chargements de pages traditionnels ?
Malheureusement, non. Pas encore, en tout cas.
Il n'existe pas de méthode standardisée pour créer une SPA aujourd'hui. Même parmi les SPA et les bibliothèques de routage populaires, l'expérience utilisateur peut être très différente d'une application à l'autre:
- Certaines SPA ne mettent à jour l'URL que lors du chargement d'un nouveau contenu "plein écran", tandis que d'autres sites mettent à jour l'URL pour de petites modifications de contenu ou même simplement pour des modifications de l'état de l'UI.
- Certaines SPA mettent à jour l'URL à l'aide de l'API History, tandis que d'autres utilisent des modifications de hachage pour prendre en charge les anciens navigateurs (et d'autres ne mettent pas du tout à jour l'URL).
- Certaines SPA chargent le contenu, puis mettent à jour l'URL, tandis que d'autres mettent à jour l'URL avant de charger le contenu.
- Certaines SPA chargent le contenu en une seule fois, de manière synchrone, dans une seule tâche JavaScript, tandis que d'autres effectuent la transition du contenu de manière asynchrone, sur plusieurs tâches (sans événement de fin de transition clair).
- Certaines SPA chargent toujours le contenu à partir du réseau, tandis que d'autres préchargent l'intégralité du contenu à l'avance afin que les modifications de route soient chargées instantanément à partir de la mémoire.
Ces différences rendent très difficile la définition et l'identification de ce qui constitue une modification de route SPA, ou même une SPA elle-même, à grande échelle.
Dans certains cas, un changement de route SPA est logiquement identique à une page chargée par MPA. Dans ce cas, il serait idéal que les métriques Core Web Vitals existantes puissent être appliquées.
Toutefois, sans heuristiques solides pour identifier de manière fiable les changements de parcours "réels" de toutes les autres modifications d'URL, ainsi que des signaux clairs marquant le début et la fin de ces transitions, le reporting des métriques Core Web Vitals dans ces cas obscurcirait les données et les rendrait moins utiles ou moins représentatives de l'expérience utilisateur réelle sur le site.
Les SPA sont-elles plus difficiles à optimiser pour les Core Web Vitals que les MPA ?
Rien n'empêche intrinsèquement une page dans une SPA de se charger aussi rapidement (et d'obtenir un score aussi élevé pour toutes les métriques Core Web Vitals) qu'une page similaire dans une MPA.
Toutefois, les MPA correctement optimisées présentent certains avantages pour atteindre les seuils Core Web Vitals que les SPA ne possèdent pas actuellement. En effet, avec l'architecture MPA, chaque "page" est chargée en tant que navigation sur une page complète (plutôt que de récupérer dynamiquement le contenu et de l'insérer dans la page existante), ce qui signifie que les utilisateurs qui accèdent à une MPA sont plus susceptibles de charger plusieurs pages du site. Par conséquent, un pourcentage plus élevé de la distribution de toutes les pages chargées pour une MPA impliquera que certaines ou toutes les sous-ressources seront mises en cache.
Certes, pour qu'une MPA obtienne de meilleures performances que les SPA sur les métriques Core Web Vitals, plusieurs conditions doivent être remplies:
- La MPA doit avoir optimisé la mise en cache des sous-ressources afin de s'assurer que les chargements de pages de même origine sont effectivement plus rapides que les chargements de pages intersites au 75e percentile.
- Les utilisateurs qui accèdent à des pages AMP doivent consulter plusieurs pages pour que le site bénéficie des avantages de la mise en cache, ce qui accélère le chargement des pages.
Étant donné que les évaluations des métriques Core Web Vitals tiennent compte du 75e percentile des visites de pages, un plus grand nombre de visites de pages performantes dans l'ensemble de données augmente la probabilité que la visite au 75e percentile de la distribution se situe dans les seuils recommandés.
Notez qu'il est important de tenir compte de la façon dont les données sont agrégées lorsque vous comparez les scores Core Web Vitals. Autrement dit, vous devez savoir si l'ensemble de données de la distribution inclut toutes les pages de votre site ou de votre origine, ou uniquement les chargements de pages pour une URL de page spécifique.
Lorsque vous agrégez les scores de toutes les pages d'une origine, les pages rapides individuelles peuvent améliorer le 75e percentile de l'origine dans son ensemble. Toutefois, lorsque vous effectuez une agrégation par page, les scores d'une page n'affectent pas ceux de la suivante. En d'autres termes, lorsque vous agrégez les scores d'une MPA par page, les chargements rapides du cache observés sur la page de paiement n'amélioreront pas les scores des chargements initiaux lents sur la page de destination du site.
Vous pouvez vérifier le score de votre site pour différentes méthodes d'agrégation à l'aide de PageSpeed Insights ou de l'API Rapport d'expérience utilisateur Chrome, qui indique les scores pour les URL de pages individuelles et pour l'ensemble de l'origine.
L'architecture SPA peut également affecter les scores Core Web Vitals pour les métriques qui prennent en compte la durée de vie complète d'une page. Étant donné que les utilisateurs qui accèdent à des SPA ont tendance à rester sur la même "page" pendant toute la session, les métriques qui s'accumulent au fil du temps peuvent être plus sévères pour les SPA que pour les MPA.
En avril 2021, nous avons annoncé des modifications de la métrique CLS qui ont partiellement résolu ce problème. Auparavant, le CLS s'accumulait sur toute la durée de vie de la page, alors qu'il ne s'accumule désormais que sur une période spécifique, essentiellement la pire rafale de décalages de mise en page sur une page donnée.
Toutefois, même avec la nouvelle définition du CLS, les SPA sont toujours désavantagés, car la valeur du CLS n'est pas "réinitialisée" après une transition de route comme elle le fait avec les chargements de page complets dans une MPA. Cela peut également prêter à confusion, car les changements de mise en page qui se produisent après une transition de parcours seront attribués à l'URL de la page au moment de son chargement, et non à l'URL dans la barre d'adresse au moment du changement (plus d'informations ci-dessous).
Si les architectures SPA améliorent l'expérience utilisateur, cette amélioration ne devrait-elle pas se refléter dans les métriques ?
Oui, c'est le cas. Toutefois, comme indiqué précédemment, il est difficile de quantifier l'amélioration de l'expérience à grande échelle, compte tenu de toutes les différentes manières dont les SPA sont implémentées sur le Web aujourd'hui.
En réalité, l'industrie des performances Web (y compris Google) n'a historiquement pas investi autant de temps et d'efforts dans le développement de métriques axées sur l'utilisateur pour les performances post-chargement d'une page que pour le chargement de la page lui-même. Ce n'est pas parce que les performances post-chargement ne sont pas importantes, mais parce que l'expérience utilisateur et les interactions post-chargement sont beaucoup plus variées et moins bien définies, ce qui rend difficile la conception de métriques pour elles.
Toutefois, même si nous disposions de métriques post-chargement bien définies pour mesurer les performances des SPA, nous ne voudrions pas ignorer l'expérience de chargement simplement parce que l'expérience post-chargement s'est améliorée.
L'un des objectifs de l'initiative Web Vitals est de promouvoir et d'inciter à de bonnes expériences utilisateur dans autant d'aspects du chargement et de l'utilisation d'une page Web que possible. Nous ne souhaitons pas encourager les scénarios où les mauvaises expériences sont justifiées si vous pouvez compenser par suffisamment de bonnes expériences. Les utilisateurs veulent que les pages se chargent rapidement et qu'ils puissent passer rapidement à de nouveaux contenus. Nous avons donc essayé de concevoir des métriques qui favorisent ces types d'expériences.
Bien qu'il soit vrai qu'une version MPA d'un site puisse mieux performer en termes de métriques Core Web Vitals au 75e percentile qu'une version SPA du même site, la version SPA doit tout de même s'efforcer d'atteindre le seuil "bon". Si la version SPA ne répond pas au seuil "bon" pour la plupart des utilisateurs, l'expérience de chargement initiale n'est probablement toujours pas perçue comme bonne, même si l'expérience de navigation ultérieure sur la page est excellente.
À l'avenir, nous prévoyons de développer des métriques qui encouragent les expériences post-chargement de haute qualité. Nous pensons que c'est le meilleur moyen d'inciter les SPA de haute qualité sans compromettre l'expérience de chargement initiale. Nous avons déjà publié une nouvelle métrique appelée Interaction to Next Paint (INP) qui mesure la latence d'interaction tout au long du cycle de vie de la page. Nous travaillons également activement sur d'autres métriques post-chargement, y compris celles qui mesurent les transitions de routes SPA (voir ci-dessous).
Nous avons remplacé notre MPA par une SPA, et nos scores ont baissé. Est-ce normal ?
Cela dépend. Plusieurs raisons peuvent expliquer la modification de vos scores après une migration d'architecture majeure, mais une diminution du nombre de chargements de cache chaud peut en partie expliquer cette évolution.
Pour vérifier rapidement, vous pouvez tester une version MPA et une version SPA de l'une de vos pages de destination avec Lighthouse. Si le score Lighthouse est inférieur pour l'une des métriques Core Web Vitals de la version SPA, il est probable que l'expérience de chargement se soit dégradée après la mise à jour.
Dois-je passer d'une SPA à une MPA pour améliorer les métriques Core Web Vitals de mon site ?
Probablement pas. Ne passez d'une SPA à une MPA que si vous n'êtes pas satisfait de votre pile SPA et si vous avez des raisons de penser qu'une MPA offrira une meilleure expérience utilisateur.
Au fil du temps, à mesure que les métriques Core Web Vitals s'amélioreront et couvriront une plus grande partie de l'expérience de navigation, les équipes disposant d'applications SPA bien conçues qui offrent une excellente expérience utilisateur devraient s'attendre à ce que leurs scores Core Web Vitals le reflètent.
Si les scores Core Web Vitals ne sont signalés que pour les pages de destination d'une SPA, comment puis-je déboguer les problèmes qui se produisent sur les "pages" après une transition de route ?
Les outils Google qui fournissent des données sur le terrain pour la métrique Core Web Vitals (comme la Search Console et PageSpeed Insights) obtiennent leurs données à partir du rapport d'expérience utilisateur Chrome (CrUX). CrUX regroupe les données par origine ou par URL de la page (c'est-à-dire l'URL de la page au moment du chargement).
Pour toutes les raisons déjà listées ci-dessus, CrUX ne peut pas agréger les données par parcours SPA. Toutefois, en tant que propriétaire de site qui connaît votre propre architecture, vous pouvez le mesurer vous-même. De nombreux outils d'analyse vous permettent de signaler un changement de route SPA et de mettre à jour vos données de mesure en conséquence.
Lorsque vous mesurez les métriques Web Vitals avec un outil d'analyse, assurez-vous de mesurer à la fois l'URL de l'itinéraire actuel et l'URL de la page d'origine. Vous pourrez ainsi déboguer les problèmes individuels qui se produisent tout au long du cycle de vie de la page, et agréger les données par URL de la page d'origine afin de correspondre à la façon dont les outils Google mesurent et génèrent des rapports sur les métriques.
Pour en savoir plus et connaître les bonnes pratiques, consultez Déboguer les performances sur le terrain.
Que fait Google pour s'assurer que les MPA n'ont pas un avantage injuste par rapport aux SPA ?
Comme indiqué ci-dessus, une MPA correctement optimisée peut, dans certains cas, afficher de meilleurs scores Web Vitals au 75e percentile, car elle aura probablement un pourcentage plus élevé de visites de pages mises en cache. À l'inverse, aucune des métriques Core Web Vitals ne permet actuellement de mesurer les améliorations réelles de l'expérience utilisateur dans les SPA correctement optimisées.
Chez Google, nous sommes conscients que cela crée des incitations qui ne correspondent pas entièrement aux objectifs de l'initiative Web Vitals. Nous cherchons activement à y remédier. Nous étudions actuellement deux solutions potentielles, l'une à court terme et l'autre à plus long terme:
- Évaluez les visites de pages multi-origines et celles de pages de même origine séparément.
- Concevoir de nouvelles API permettant de mieux mesurer les SPA
Évaluer séparément les visites de pages multi-origines et celles de pages de même origine
Aujourd'hui, les métriques Core Web Vitals regroupent toutes les visites de pages dans un seul bucket. Elles ne font pas la distinction entre les visites de nouveaux utilisateurs et celles de visiteurs réguliers, ni entre les pages de destination et les pages de paiement, ni entre tout autre type d'agrégation où l'état du cache peut avoir un impact sur les performances.
Une façon de normaliser les différences entre les performances des SPA et des MPA consiste à appliquer des pondérations différentes aux différents types de visites, voire avec des recommandations de seuil complètement différentes.
Bien que nous souhaitions récompenser les implémentations de cache efficaces, nous ne voulons pas que les navigations intrasites rapides puissent masquer les chargements lents des pages de destination. Nous ne voulons pas non plus inciter les sites à diviser les pages longues en plusieurs pages plus courtes uniquement dans le but d'améliorer les scores des métriques.
En évaluant séparément les visites de pages cross-origin et same-origin, nous pouvons nous assurer que ces deux types d'expériences sont importants, sans laisser la popularité relative d'un type sur un site donné fausser la distribution d'une métrique particulière.
Concevoir de nouvelles API permettant de mieux mesurer les SPA
Une autre solution en cours de développement (en parallèle de la solution ci-dessus) est une nouvelle API App History, qui aiderait à standardiser les modèles SPA actuels et à mesurer et comprendre plus facilement l'utilisation des SPA à grande échelle.
L'API App History introduit un nouvel événement navigate, qui présente deux fonctionnalités clés spécifiques à la mesure des SPA:
- Un indicateur
userInitiated, qui ne sera défini sur "true" que si la navigation a été lancée via un clic sur un lien, l'envoi d'un formulaire ou l'UI de navigation avant ou arrière du navigateur. - Une méthode
transitionWhile(), qui utilise une promesse permettant au développeur de signaler lorsque le travail qu'il a lancé pour effectuer la navigation est terminé.
L'indicateur userInitiated peut être utilisé pour déterminer un point de départ sémantique pour une transition de route SPA, ce qui indique un intent utilisateur clair. La résolution de la promesse transitionWhile() peut aider le navigateur à corréler les peintures avec la transition de route spécifique, de sorte qu'il puisse déterminer la plus grande peinture à contenu liée à cette transition.
En s'appuyant sur l'idée présentée dans la section précédente, il est même possible d'agréger le temps de transition de la route SPA dans le même bucket que les chargements de pages de même origine dans une MPA. Cette fonctionnalité est intéressante, car elle permet à un site qui migre d'une MPA vers une SPA de comparer les performances avant et après.
Bien entendu, des recherches supplémentaires sont nécessaires pour savoir si nous pouvons déterminer avec précision ces éléments. Si vous avez des suggestions ou des commentaires sur ces propositions, veuillez envoyer un e-mail à l'adresse web-vitals-feedback@googlegroups.com.
Conclusions
Google s'engage à améliorer les métriques Web Vitals et à s'assurer qu'elles mesurent et incitent à des expériences de haute qualité qui sont importantes pour les utilisateurs. Cela dit, nous sommes conscients que des écarts de mesure existent aujourd'hui. Pour le moment, les métriques ne couvrent pas tous les aspects de l'expérience utilisateur, mais nous travaillons activement à combler ces lacunes.
Malgré les limites actuelles, nous pensons que les domaines que les métriques existantes capturent sont essentiels à la santé et au succès du Web. Dans la mesure où les sites (quelle que soit leur architecture) ne respectent pas les seuils recommandés, nous pensons qu'il y a place pour l'amélioration.
J'espère que cet article vous aura éclairé sur ce sujet complexe et nuancé. Comme toujours, si vous avez des commentaires sur les métriques Web Vitals actuelles ou futures, veuillez envoyer un e-mail à l'adresse web-vitals-feedback@googlegroups.com.