Réponses aux questions fréquentes sur les applications monopages, les métriques Core Web Vitals et le plan de Google pour remédier aux limites actuelles liées aux mesures.
Depuis le lancement de l'initiative Signaux Web en mai 2020, l'équipe Chrome a reçu un grand nombre de questions et de commentaires pertinents à propos du programme.
Le sujet sur lequel nous avons reçu le plus de questions, et c'est sans doute la plus difficile à répondre, est peut-être de savoir comment mesurer les Core Web Vitals dans une application monopage (SPA) et comment les architectures SPA affectent les scores Core Web Vitals.
Il est difficile de répondre à ces questions, car le problème est assez nuancé. Dans cet article, nous allons donc nous efforcer de répondre aux questions les plus courantes, en fournissant autant de détails et de contexte que possible.
Toutefois, 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ées pour créer un site. Nous pensons que les applications monopages (SPA) et les applications multipages (MPA) sont toutes deux capables d'offrir une expérience de haute qualité aux utilisateurs. Notre intention avec l'initiative Web Vitals est de fournir des métriques qui mesurent l'expérience indépendamment de la technologie. Bien que cela ne soit pas possible dans tous les cas aujourd'hui (en raison des limitations de la plate-forme Web), nous travaillons activement à combler ces lacunes.
Questions fréquentes
Les métriques Core Web Vitals incluent-elles les transitions d'itinéraire SPA ?
Non. Chacune des métriques Core Web Vitals est mesurée par rapport à la navigation actuelle sur les pages de premier niveau. Si une page charge dynamiquement un nouveau contenu et met à jour l'URL de la page dans la barre d'adresse, cela n'a aucune incidence 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 correspond à l'URL à laquelle l'utilisateur a accédé et qui a lancé le chargement de la page.
Les métriques Core Web Vitals traitent-elles les modifications d'itinéraire SPA de la même manière que les chargements de page traditionnels ?
Malheureusement, non. Pas encore.
Il n'existe aujourd'hui aucune méthode standardisée pour créer une SPA. Même parmi les bibliothèques SPA et de routage populaires, l'expérience utilisateur peut être très différente d'une application à l'autre:
- Certaines applications monopages ne mettent à jour l'URL que lors du chargement d'un nouveau contenu de "page entière", tandis que d'autres sites mettent à jour l'URL pour les modifications mineures du contenu ou même simplement pour les changements d'état de l'interface utilisateur.
- Certaines applications monopages mettent à jour l'URL à l'aide de l'API History, tandis que d'autres modifient le hachage afin de prendre en charge des navigateurs plus anciens (et d'autres ne mettent pas à jour l'URL du tout).
- Certaines applications monopages chargent le contenu, puis mettent à jour l'URL, tandis que d'autres mettent à jour l'URL avant de charger le contenu.
- Certaines applications monopages chargent le contenu simultanément, de manière synchrone, dans une seule tâche JavaScript, tandis que d'autres effectuent la transition du contenu de manière asynchrone entre plusieurs tâches (sans événement de fin de transition clair).
- Certaines applications Web monopages chargent toujours le contenu à partir du réseau, tandis que d'autres préchargent tout le contenu à l'avance afin que les modifications de route soient chargées instantanément depuis la mémoire.
En raison de ces différences, il est très difficile de définir et d'identifier ce qui constitue une modification d'itinéraire SPA, voire une SPA elle-même, à grande échelle.
Dans certains cas, une modification d'itinéraire SPA est logiquement identique au chargement d'une page MPA. Dans ce cas, il serait judicieux d'appliquer les métriques Core Web Vitals existantes.
Toutefois, sans méthodes heuristiques solides permettant d'identifier de manière fiable les changements d'itinéraire "réels" par rapport à toutes les autres modifications d'URL, ainsi que des signaux clairs indiquant le début et la fin de ces transitions, générer des rapports sur les métriques Core Web Vitals dans ce cas brouillerait les données et les rendrait moins utiles ou moins représentatives de l'expérience utilisateur réelle sur le site.
Est-il plus difficile pour les SPA d'obtenir de bons résultats dans Core Web Vitals que les APM ?
Rien n'empêche une page dans une SPA de se charger aussi rapidement (et d'obtenir des scores tout aussi bien pour toutes les métriques Core Web Vitals) qu'une page similaire dans une MPA.
Toutefois, les APA correctement optimisées présentent certains avantages par rapport aux seuils d'activité Core Web Vitals qu'elles n'atteignent pas actuellement. En effet, avec l'architecture MPA, chaque "page" est chargée en tant que navigation pleine page (plutôt que de récupérer dynamiquement le contenu et de l'insérer dans la page existante). Cela signifie que les utilisateurs qui consultent une MPA sont plus susceptibles de charger plusieurs pages à partir du site. Par conséquent, un pourcentage plus important de tous les chargements de page d'une MPA implique la mise en cache d'une partie ou de la totalité des sous-ressources.
Il est vrai que pour qu'une MPA fonctionne mieux avec les métriques Core Web Vitals qu'une SPA, quelques conditions doivent être remplies:
- La MPA doit optimiser la mise en cache des sous-ressources afin que les chargements de pages à la même origine soient effectivement plus rapides que les chargements de pages multi-origines au 75e centile.
- Les utilisateurs qui accèdent aux MPA doivent visiter plusieurs pages pour que le site bénéficie des avantages de mise en cache qui accélèrent le chargement des pages.
Étant donné que les évaluations Core Web Vitals prennent en compte le 75e centile des visites de la page, le fait d'inclure dans l'ensemble de données un plus grand nombre de visites de pages performantes dans l'ensemble de données augmentera la probabilité que la visite au 75e centile de la distribution entre dans les seuils recommandés.
Notez qu'il est important de prendre en compte la manière dont les données Core Web Vitals sont comparées, c'est-à-dire 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 page pour une URL de page spécifique.
Lors de l'agrégation des scores de toutes les pages d'une origine, les pages rapides individuelles peuvent améliorer le 75e centile de l'origine dans son ensemble. Toutefois, lors de l'agrégation par pages individuelles, les scores d'une page n'affectent pas ceux de la suivante. En d'autres termes, lors de l'agrégation des scores d'une MPA par page, les chargements de cache rapides sur la page de paiement n'améliorent pas les scores de chargement initial lents enregistrés sur la page de destination du site.
Vous pouvez vérifier le score de votre site en fonction de différentes méthodes d'agrégation à l'aide de PageSpeed Insights ou de l'API Chrome User Experience Report, qui indique les scores pour les URL de chaque page 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 aux applications monopages 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 ces applications que pour celles-ci.
En avril 2021, nous avons annoncé des modifications apportées à la métrique CLS qui résout partiellement ce problème. Auparavant, le CLS s'accumulait sur toute la durée de vie d'une page, alors qu'il ne s'accumule désormais que sur une fenêtre de temps spécifique, ce qui correspond 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 applications monopages sont toujours désavantagées, car la valeur CLS n'est pas "réinitialisée" après la transition d'un itinéraire, comme c'est le cas avec le chargement d'une page entière dans une MPA. Cela peut également prêter à confusion, car les changements de mise en page qui se produisent après une transition d'itinéraire sont attribués à l'URL de la page lors de son chargement, et non à l'URL figurant dans la barre d'adresse au moment du changement (plus de détails 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, cela devrait être le cas. Toutefois, comme indiqué précédemment, il est difficile de quantifier l'ampleur de l'amélioration de l'expérience à grande échelle, compte tenu des différentes façons dont les applications monopages sont mises en œuvre actuellement sur le Web.
En réalité, le secteur des performances Web (y compris Google) n'a jamais consacré autant de temps et d'efforts au développement de métriques centrées sur l'utilisateur pour les performances post-chargement d'une page que pour le chargement de la page elle-même. En effet, les performances post-chargement ne sont pas importantes, mais 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 eux.
Toutefois, même si nous disposions de métriques post-charge bien définies pour mesurer les performances de l'application monopage, nous ne voudrions pas ignorer le chargement simplement parce que l'expérience post-chargement s'est améliorée.
L'un des objectifs du projet Core Web Vitals est de promouvoir et d'encourager des expériences utilisateur de qualité pour un maximum d'aspects du chargement et de l'utilisation d'une page Web. Nous ne voulons pas vous encourager dans des scénarios dans lesquels de mauvaises expériences sont justifiées si vous pouvez en offrir suffisamment pour les rattraper. Les utilisateurs veulent que leurs pages se chargent rapidement et qu'ils passent rapidement au nouveau contenu. Nous avons donc essayé de concevoir des métriques qui favorisent ce type d'expérience.
Ainsi, même s'il est vrai qu'une version MPA d'un site obtient de meilleurs résultats pour les métriques Core Web Vitals au 75e centile qu'une version SPA du même site, la version SPA doit tout de même s'efforcer d'atteindre le seuil "satisfaisant". Si la version de l'application monopage n'atteint pas le seuil "satisfaisant" pour la plupart des utilisateurs, l'expérience de chargement initial n'est probablement toujours pas perçue comme étant de bonne qualité, même si l'expérience de navigation sur la page suivante est excellente.
À l'avenir, nous prévoyons de développer des métriques qui encouragent des expériences de post-charge de qualité. Nous pensons qu'il s'agit de la meilleure façon d'encourager les applications Web monopages de haute qualité sans compromettre l'expérience de chargement initial. 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 des métriques qui mesurent les transitions de route SPA (voir ci-dessous).
Nous sommes passés d'une MPA à une SPA, et nos scores ont diminué. Est-ce normal ?
Cela dépend. Plusieurs raisons peuvent expliquer pourquoi vos scores peuvent changer après une migration majeure de l'architecture, mais une baisse du nombre de chargements de cache tiède peut expliquer une partie de ce changement.
Pour vous en assurer rapidement, vous pouvez tester à la fois une version MPA et SPA de l'une de vos pages de destination avec Lighthouse. Si le score Lighthouse est plus faible pour l'une des métriques Core Web Vitals pour la version SPA, il est probable que l'expérience de chargement se soit dégradée après la mise à jour.
Dois-je remplacer mon site SPA par une MPA pour améliorer les Core Web Vitals ?
Probablement pas. Vous ne devez passer d'une SPA à une MPA que si vous n'êtes pas satisfait de votre pile SPA et que 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éliorent et couvrent une plus grande partie de l'expérience de navigation complète, les équipes qui disposent de SPA bien conçues et qui offrent une expérience utilisateur de qualité doivent s'attendre à ce que leurs scores Core Web Vitals reflètent cela.
Si les scores Core Web Vitals ne sont consignés que pour les pages de destination d'une application monopage, comment puis-je déboguer les problèmes qui se produisent sur les "pages" après la transition d'un itinéraire ?
Les outils Google qui génèrent des rapports sur les données des champs pour la métrique Core Web Vitals (comme la Search Console et PageSpeed Insights) obtiennent leurs données du rapport d'expérience utilisateur Chrome (CrUX). CrUX agrège les données par origine ou par URL de page (c'est-à-dire l'URL de la page au moment du chargement).
Pour toutes les raisons déjà indiquées ci-dessus, CrUX n'est pas en mesure d'agréger les données par route SPA. Toutefois, en tant que propriétaire de site connaissant votre propre architecture, vous pouvez mesurer cela vous-même. De nombreux outils d'analyse vous permettent de signaler lorsqu'une modification d'itinéraire SPA est en cours et ils mettent à jour vos données de mesure en conséquence.
Lorsque vous mesurez les métriques Web Vitals à l'aide d'un outil d'analyse, assurez-vous de mesurer à la fois l'URL actuelle de la route et l'URL de la page d'origine. Cela vous permettra de déboguer à la fois les problèmes individuels qui se produisent tout au long du cycle de vie de la page et de les agréger par URL de la page d'origine afin de correspondre à la façon dont les outils Google mesurent les métriques et génèrent des rapports sur ces métriques.
Pour en savoir plus et connaître les bonnes pratiques à ce sujet, consultez la section Déboguer les performances sur le terrain.
Que fait Google pour s'assurer que les MPA ne bénéficient pas d'un avantage déloyal par rapport aux applications monopages ?
Comme indiqué ci-dessus, une MPA correctement optimisée peut, dans certains cas, enregistrer de meilleurs scores Web Vitals au 75e centile, car le pourcentage de visites de pages mises en cache sera probablement plus élevé. À l'inverse, les métriques Core Web Vitals n'enregistrent actuellement aucune amélioration réelle de l'expérience utilisateur dans les applications monopages correctement optimisées.
Chez Google, nous reconnaissons que cela génère des incitations qui ne correspondent pas totalement aux objectifs du projet Core Web Vitals et nous recherchons activement des moyens d'y remédier. Nous étudions actuellement deux solutions potentielles, une à court terme et une à plus long terme:
- Évaluez séparément les visites sur les pages multi-origines et celles provenant de la même origine.
- Concevoir de nouvelles API qui permettent une meilleure mesure des SPA
Évaluer séparément les visites sur les pages multi-origines et celles provenant de la 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 différence entre les nouvelles visites ou pages de destination, les nouvelles pages de destination et les pages de paiement, ni tout autre type d'agrégation où l'état du cache pourrait avoir un impact sur les performances.
Pour normaliser les différences de performances entre l'ASP et l'APM, vous pouvez appliquer une pondération différente aux différents types de visites, éventuellement même avec des recommandations de seuil complètement différentes.
Bien que nous souhaitions récompenser les implémentations de cache efficaces, nous ne souhaitons pas que les navigations rapides au sein d'un site puissent couvrir la lenteur de chargement de la page de destination. Nous ne voulons pas non plus encourager les sites à scinder les longues pages en un ensemble de pages plus courtes dans le seul but d'améliorer les scores des métriques.
En évaluant séparément les visites multi-origines et les visites de même origine, nous pouvons nous assurer que ces deux types d'expériences sont importants sans pour autant laisser la popularité relative d'un type sur un site donné fausser la distribution d'une métrique particulière.
Concevoir de nouvelles API qui permettent une meilleure mesure des SPA
Une autre solution sur laquelle nous travaillons activement (en parallèle à ce qui précède) est la nouvelle API App History. Elle devrait aider à standardiser les modèles d'application monopage actuelle et faciliter la mesure et la compréhension de l'utilisation de l'application monopage à 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 applications monopages:
- Un indicateur
userInitiated, qui n'est 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'interface utilisateur "Précédent" ou "Suivant" du navigateur - Une méthode
transitionWhile(), qui prend une promesse permettant au développeur d'indiquer que le travail qu'il a lancé pour effectuer la navigation est terminé.
L'option userInitiated peut être utilisée pour déterminer le point de départ sémantique d'une transition de route SPA, indiquant clairement l'intention de l'utilisateur. La promesse de résolution transitionWhile() peut aider le navigateur à corréler les peintures avec la transition d'itinéraire spécifique, afin qu'il puisse déterminer la plus grande valeur Contentful Paint liée à cette transition.
En plus de l'idée présentée dans la section précédente, il est même possible d'agréger le temps de transition des routes SPA dans le même bucket que les chargements de page de même origine dans une MPA. C'est intéressant, car cela permettrait à un site migré d'une MPA vers une SPA de comparer réellement les performances avant et après.
Bien sûr, davantage de recherches sont nécessaires avant de savoir si nous pouvons prendre ces décisions avec précision. 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 Core Web Vitals, et à s'assurer qu'elles mesurent et encouragent les expériences de haute qualité qui sont importantes pour les utilisateurs. Cela dit, nous sommes conscients qu'il existe aujourd'hui des lacunes au niveau des mesures. Actuellement, ces métriques ne couvrent pas tous les aspects de l'expérience utilisateur, mais nous mettons tout en œuvre pour combler ces lacunes.
Malgré les limites actuelles, nous pensons que les domaines pris en compte par les métriques existantes 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 est possible de les améliorer.
J'espère que cet article vous a permis de mieux comprendre ce sujet complexe et nuancé. Comme toujours, si vous avez des commentaires sur les métriques actuelles ou futures des métriques Core Web Vitals, veuillez envoyer un e-mail à l'adresse web-vitals-feedback@googlegroups.com.