Réponses aux questions fréquentes sur les applications monopages, les métriques Core Web Vitals et le plan de Google pour faire face aux limitations actuelles des mesures.
Depuis le lancement de l'initiative Web Vitals en mai 2020, nous de l'équipe Chrome ont reçu un grand nombre de questions et de commentaires intéressants programme.
Le sujet sur lequel nous avons reçu le plus de questions, La question la plus difficile à se poser est de savoir comment mesurer les métriques Core Web Vitals dans un application monopage et leur impact sur les scores Core Web Vitals.
Il est difficile de répondre à ces questions, car le problème est assez nuancé. ce post, nous allons 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, cependant, il est important de préciser que Google n'ont aucune préférence quant à l'architecture ou à la technologie utilisée sur votre site. Nous pensons que les applications monopages et les applications multipages d'offrir des expériences de grande qualité aux utilisateurs, et notre intention en ce qui concerne le Web L'initiative Vitals consiste à fournir des métriques qui mesurent l'expérience de la technologie. Bien que cela ne soit pas toujours possible de nos jours (en raison de les limites de la plate-forme Web), nous travaillons activement à la fermeture de ces les écarts.
Questions fréquentes
Les métriques Core Web Vitals incluent-elles les transitions de routage SPA ?
Non. Chacune des métriques Core Web Vitals est mesurée par rapport aux métriques actuelles, une navigation sur les pages de premier niveau. Si une page charge dynamiquement de nouveaux et met à jour l'URL de la page dans la barre d'adresse, il n'est associé à aucun sur la façon dont les métriques Core Web Vitals sont mesurées. Les valeurs des métriques ne sont pas réinitialisée, et l'URL associée à chaque mesure de métrique est celle que l'utilisateur auquel vous avez accédé à l'origine du chargement de la page.
Les métriques Core Web Vitals peuvent-elles traiter les modifications de routage SPA de la même manière que les chargements de page traditionnels ?
Malheureusement, non. Pas encore du tout.
Il n'existe pas de méthode standardisée aujourd'hui pour créer une application monopage, et même parmi les SPA et bibliothèques 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 de la nouvelle page "pleine page". contenus, tandis que d'autres sites mettent à jour l'URL en cas de modifications mineures du contenu, voire uniquement de l'état de l'interface utilisateur. des modifications.
- Certains SPA mettent à jour l'URL à l'aide de l'API History, tandis que d'autres utilisent le hachage afin de prendre en charge des navigateurs plus anciens (et dans les autres cas, l'URL n'est pas mise à jour du tout).
- Certaines applications monopages chargent du contenu, puis mettent à jour l'URL, tandis que d'autres mettent à jour l'URL. avant de charger le contenu.
- Certains SPA chargent le contenu en une seule fois, de manière synchrone, dans un d'une tâche, tandis que d'autres transfèrent le contenu, de manière asynchrone, entre plusieurs (sans événement de fin de transition clair).
- Certaines applications monopages chargent toujours le contenu depuis le réseau, tandis que d'autres préchargent tous contenu à l'avance afin que les changements d'itinéraire se chargent instantanément à partir de la mémoire.
Ces différences permettent de définir et d'identifier ce qui constitue une route SPA ou même une application monopage, très difficile à réaliser à grande échelle.
Dans certains cas, une modification de route SPA est logiquement identique au chargement d'une page MPA, Dans ce cas, il est préférable que les métriques Core Web Vitals existantes peut être appliquée.
Cependant, sans heuristique solide permettant d'identifier de manière fiable les données "vraies" modifications d'itinéraire à partir de toutes les autres modifications d'URL, ainsi que des signaux clairs indiquant le début et la fin de telles transitions, la création de rapports sur les métriques Core Web Vitals dans ces cas serait boueuse les données et les rendre moins utiles ou moins représentatives de l’expérience utilisateur réelle sur le site.
Est-il plus difficile pour les applications Web monopages d'obtenir de bons résultats avec les métriques Core Web Vitals ?
Il n'y a rien de inhérent à l'architecture SPA qui pourrait empêcher une page dans une SPA de se charger tout aussi vite et d'attribuer des scores tout aussi bien sur tous les les métriques Core Web Vitals, sous la forme d'une page similaire dans une approbation multipartite.
Toutefois, des MPA correctement optimisés présentent certains avantages pour répondre aux exigences du Core Web Seuils d'importance vitale que les applications monopages ne fonctionnent pas actuellement. En effet, avec l'approbation multipartite, de l'architecture, chaque "page" est chargée en tant que navigation sur toute la page (au lieu de récupère le contenu de manière dynamique et l'insère dans la page existante), ce qui signifie que les utilisateurs qui consultent une approbation multipartite sont plus susceptibles de charger plus d'une page ce qui signifie qu'un plus grand pourcentage de la distribution les chargements de page pour une MPA impliqueront tout ou partie des sous-ressources mis en cache.
Certes, une MPA est plus efficace sur les métriques Core Web Vitals qu'une application monopage certaines choses doivent être vraies:
- L'approbation multipartite doit disposer d'une mise en cache optimisée des sous-ressources afin d'assurer les chargements de pages depuis la même origine sont en effet plus rapides que les chargements de pages multi-origines 75e centile.
- Les utilisateurs qui accèdent à des MPA doivent visiter plusieurs pages pour que le site bénéficier des avantages de la mise en cache qui accélèrent le chargement des pages.
Puisque les évaluations Core Web Vitals considèrent que le 75 centile de la page les visites, le fait d'avoir 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 en respectant les seuils recommandés.
Notez qu'il est important de prendre en compte les scores Core Web Vitals correspond à la manière dont les données sont agrégées, c'est-à-dire si l'ensemble de données de la distribution inclut toutes les pages de votre site ou de son origine, ou uniquement les chargements de pages pour un l'URL de la page.
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 page, le score d'une page n'affecte pas celui de l'utilisateur suivant. En d'autres termes, lors de l'agrégation des scores d'une MPA par page, le cache rapide sur la page de paiement n'améliorent pas le score des problèmes de lenteur lors de 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 Rapport sur l'expérience utilisateur de Chrome API, qui consigne les scores à la fois pour les URL des pages individuelles et pour l'origine entière.
Une autre façon dont l'architecture SPA peut affecter les scores Core Web Vitals est qui tiennent compte de la durée de vie complète d'une page. Puisque les utilisateurs utilisant des applications monopages ont tendance à rester sur la même "page" pour l'ensemble de la session, les métriques qui s'accumulent au fil du temps peut être plus sévère avec les SPA que les MPA.
En avril 2021, nous avons annoncé des modifications de la métrique CLS qui a partiellement résolu ce problème. Auparavant, le CLS s'accumulait sur la durée de vie complète d'une page, alors qu'elle ne s'accumule que sur une fenêtre temps, il s'agit essentiellement de la pire rafale de décalages de mise en page sur une page donnée.
Toutefois, même avec la nouvelle définition CLS, les applications monopages sont toujours en mauvais état. car la valeur CLS n'est pas « réinitialiser » après une transition d'une route avec les chargements de la pleine page dans une MPA. Cela peut également prêter à confusion, car la mise en page les décalages qui se produisent après une transition de route sont attribués à l'URL au moment de son chargement, et non l'URL dans la barre d'adresse au moment de la migration. (en savoir plus 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. Toutefois, comme nous l'avons vu, le fait de quantifier s'est améliorée est difficile à faire à grande échelle, étant donné la façon dont les applications monopages sont implémentées sur le Web aujourd’hui.
En réalité, le secteur de la performance Web (y compris Google) n'a jamais a investi presque autant de temps et d'efforts pour développer des applications axées sur l'utilisateur des métriques sur les performances post-charge que pour le chargement de la page elle-même. Cela n'est pas dû au fait que le post-chargement les performances n'ont pas d'importance, c'est parce que l'expérience utilisateur post-charge et les interactions beaucoup plus variées et moins bien définies, ce qui complique la conception de métriques pour de l'IA générative.
Mais même si nous avions des métriques post-charge bien définies pour mesurer l'application monopage des performances, nous ne voudrions pas ignorer l'expérience de chargement simplement parce que l'expérience après le chargement s'est améliorée.
L'un des objectifs de l'initiative "Signaux Web" est de promouvoir et d'encourager l'expérience utilisateur pour tous les aspects du chargement et de l'utilisation d'une page Web, possible. Nous ne voulons pas encourager les scénarios dans lesquels des expériences négatives justifiée si vous pouvez avoir suffisamment de bonnes expériences pour les rattraper. Utilisateurs que les pages se chargent rapidement et qu'elles passent au nouveau contenu rapidement. des mesures de conception qui favorisent ces types d’expériences.
Ainsi, s'il est vrai qu'une version MPA d'un site peut être plus efficace sur le Core Web, Les métriques Android Vitals au 75e centile par rapport à une version SPA site Web, la version SPA doit toujours s'efforcer d'atteindre le « bon » de sortie. Si le La version SPA ne répond pas à la "bonne" pour la plupart des utilisateurs, le seuil initial l'expérience de chargement n'est probablement pas perçue comme bonne, même si l'affichage l'expérience de navigation sur la page est excellente.
À l'avenir, nous prévoyons de développer des métriques qui encouragent et nous pensons qu'il s'agit du meilleur moyen les applications monopages d'une manière qui ne compromet pas l'expérience de chargement initial. Nous avons a déjà fourni une nouvelle métrique appelée Interaction to Next Paint (INP), qui mesure la latence des interactions tout au long du cycle de vie de la page. Nous travaillons activement sur d'autres Les métriques post-charge également, y compris les 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 reculé. Est-ce normal ?
Cela dépend. Plusieurs raisons peuvent expliquer une variation de vos scores après une migration majeure de l'architecture, mais une diminution du nombre de chargements de cache tiède pourrait expliquer une partie du changement.
Pour le vérifier rapidement, vous pouvez tester les versions MPA et SPA de l'un de vos pages de destination avec Phare : Si le Le score Lighthouse est plus faible pour n'importe quelle métrique Core Web Vitals de l'application monopage il est probable que l'expérience de chargement s'est dégradée après mise à jour.
Dois-je passer d'une SPA à une MPA pour obtenir de meilleurs résultats dans les métriques Core Web Vitals ?
Probablement pas. Vous ne devriez passer d'une SPA à une MPA que si vous n'êtes pas satisfait avec votre pile SPA et vous avez des raisons de croire qu'une MPA offrira une meilleure l'expérience utilisateur.
Au fil du temps, à mesure que les métriques Core Web Vitals s'améliorent et couvrent de plus en plus l'intégralité l'expérience de navigation, les équipes avec des applications Web monopages bien conçues qui offrent une excellente expérience utilisateur doivent que leurs scores Core Web Vitals le reflètent.
Si les scores Core Web Vitals ne sont indiqués que pour les pages de destination d'une SPA, comment puis-je déboguer les problèmes qui surviennent sur les "pages" après une transition de route ?
Les outils Google qui génèrent des rapports sur les données de champ pour la métrique Core Web Vitals (comme la recherche la console et PageSpeed Insights) proviennent de l'outil Expérience utilisateur de Chrome. Rapport (CrUX). Enfin, l'expérience utilisateur Chrome (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à énumérées ci-dessus, CrUX n'est pas en mesure de regrouper les données par route SPA. Cependant, en tant que propriétaire d'un site connaissant votre propre architecture, vous pouvez mesurer cela vous-même, et de nombreux outils d'analyse vous permettent lorsqu'un changement d'itinéraire SPA est détecté et mettre à jour vos mesures en conséquence.
Lorsque vous mesurez les métriques des signaux Web à l'aide d'un outil d'analyse, assurez-vous mesurant à la fois l'URL de route actuelle et l'URL de la page d'origine. Cela permettra vous permettent à la fois de déboguer des problèmes individuels qui se produisent tout au long de la page cycle de vie de la page, et les agréger par URL de page d'origine afin de les adapter à la façon dont Google les outils de mesure et de rapport sur les métriques.
Pour en savoir plus et connaître les bonnes pratiques à ce sujet, consultez Déboguer les problèmes de performances dans le .
Que fait Google pour s'assurer que les MPA ne bénéficient pas d'un avantage déloyal par rapport aux SPA ?
Comme mentionné ci-dessus, une approbation multipartite correctement optimisée peut, dans certains cas, offrir le score Web Vitals au 75e centile, car il est probable enregistrent un pourcentage plus élevé de visites de pages mises en cache. À l'inverse, de réelles améliorations l'expérience utilisateur dans les applications monopages correctement optimisées ne sont pas enregistrées actuellement. par l'une des métriques Core Web Vitals.
Chez Google, nous savons que cela crée des incitations qui ne correspondent pas avec les objectifs de l'initiative "Signaux Web" et nous cherchons activement des moyens pour résoudre ce problème. Nous étudions actuellement deux solutions potentielles, l'une à court terme et une à plus long terme:
- Évaluez séparément les visites des pages d'origines multiples et de même origine.
- Concevez de nouvelles API qui permettent de mieux mesurer les applications monopages.
Évaluer séparément les visites de pages d'origines multiples et de même origine
Aujourd'hui, les métriques Core Web Vitals regroupent toutes les visites de pages en une seule ne font pas la différence entre les visites nouvelles et les visites connues ou pages, pages de paiement ou tout autre type d'agrégation où l'état du cache peut avoir un impact sur les performances.
Pour normaliser les différences de performances entre les applications monopages et MPA, appliquer différentes pondérations à différents types de visites, des valeurs de seuil complètement différentes recommandations.
Nous souhaitons récompenser les mises en cache efficaces, mais nous ne souhaitons pas veulent que la navigation rapide au sein du site puisse couvrir la lenteur de la page de destination. charge. Nous ne voulons pas non plus inciter les sites à diviser de longues pages en ensemble de pages plus courtes dans le seul but d'améliorer les scores des métriques.
En évaluant séparément les visites de pages d'origines multiples et de même origine, nous pouvons vous aider de s'assurer que les deux types d'expériences sont importants sans que le parent la popularité d'un type sur un site donné fausse la distribution d'une application la métrique.
Concevez de nouvelles API qui permettent de mieux mesurer les applications monopages
Nous travaillons activement sur une autre solution (en parallèle de la solution ci-dessus) : Une nouvelle API App History qui permettrait de standardiser les performances actuelles permettent de mesurer et de comprendre plus facilement leur utilisation à grande échelle.
L'API App History introduit une nouvelle
l'événement navigate, qui
possède deux fonctionnalités clés spécifiques à la mesure des applications monopages:
- A
userInitiatedqui ne sera défini sur "true" que si la navigation a été lancée via un le clic sur un lien, l'envoi d'un formulaire, ou l'interface utilisateur "Retour" ou "Suivant" du navigateur. - A
transitionWhile(), qui accepte une promesse permettant au développeur de signaler que le travail qu'ils ont lancées pour effectuer la navigation est terminée.
L'option userInitiated peut être utilisée pour déterminer un point de départ sémantique pour
une transition de route SPA, indiquant clairement l'intention de l'utilisateur. transitionWhile()
la résolution promet d'aider le navigateur à corréler les peintures avec la route spécifique
de sorte qu'il soit en mesure d'identifier le plus grand élément Contentful Paint
liés à cette transition.
S'appuyant sur l'idée présentée dans la section précédente, il pourrait même s'agir d'agréger les temps de transition des routes SPA dans le même bucket de même origine se charge dans une MPA. C'est intéressant, car cela permettrait à un site passer d'une MPA à une SPA pour comparer réellement les performances avant et par la suite.
Bien entendu, d'autres recherches sont nécessaires pour savoir si nous pouvons avec prendre ces décisions. Si vous avez des suggestions ou des commentaires à ce sujet les propositions, envoyez-les par e-mail [email protected].
Conclusions
Google s'engage à améliorer les métriques Core Web Vitals et à s'assurer ils mesurent et encouragent les expériences de haute qualité qui sont importantes pour utilisateurs. Cela dit, nous sommes conscients qu'il existe aujourd'hui des lacunes en termes de mesure. La ne couvrent pas actuellement tous les aspects de l'expérience utilisateur, mais nous activement pour combler ces lacunes.
En dépit des limites actuelles, nous pensons que les domaines sont essentielles à la santé et à la réussite du Web, et dans la mesure que les sites (quelle que soit leur architecture) n'atteignent pas les seuils recommandés, nous pensons que des améliorations sont possibles.
J'espère que cet article vous aura aidé à éclairer ce sujet complexe et nuancé. Comme toujours, si vous avez des commentaires sur les métriques Core Web Vitals actuelles ou futures, s'il te plaît, e-mail [email protected].