Tester la mesure des navigations douces

Barry Pollard

Yoav Weiss

Depuis son lancement, l'initiative Core Web Vitals a pour objectif de mesurer l'expérience utilisateur réelle d'un site Web, plutôt que de fournir des détails techniques sur la façon dont un site Web est créé ou chargé. Les trois métriques Core Web Vitals ont été créées en tant que métriques centrées sur l'utilisateur. Il s'agit d'une évolution par rapport à des métriques techniques existantes telles que DOMContentLoaded ou load qui mesuraient des codes temporels souvent sans rapport avec la façon dont les utilisateurs perçoivent les performances de la page. De ce fait, la technologie utilisée pour créer le site ne doit pas avoir d'impact sur son score.

La réalité est toujours un peu plus délicate que dans l'idéal, et l'architecture populaire des applications monopages n'a jamais été entièrement prise en charge par les métriques Core Web Vitals. Au lieu de charger des pages Web distinctes au fur et à mesure que l'utilisateur parcourt le site, ces applications Web utilisent ce que l'on appelle des "navigations douces", dans lesquelles le contenu de la page est modifié par JavaScript. Dans ces applications, l'illusion d'une architecture de page Web classique est maintenue en modifiant l'URL et en transférant les URL précédentes dans l'historique du navigateur pour permettre aux boutons "Précédent" et "Suivant" de fonctionner comme s'y attendent l'utilisateur.

De nombreux frameworks JavaScript utilisent ce modèle, mais chacun d'eux est différent. Étant donné que cela ne correspond pas à ce que le navigateur perçoit habituellement comme une "page", il a toujours été difficile de mesurer cet élément: où la ligne doit-elle être tracée entre une interaction sur la page actuelle et celle qui consiste à considérer celle-ci comme une nouvelle page ?

L'équipe Chrome réfléchit à ce défi depuis un certain temps déjà. Elle cherche à normaliser une définition de ce qu'est une "navigation douce", ainsi que la façon dont les Core Web Vitals peuvent être mesurées pour cela, de la même manière que pour les sites Web implémentés dans l'architecture multipage (MPA) conventionnelle. Bien qu'elle n'en soit qu'à ses débuts, l'équipe est maintenant prête à rendre ce qui a déjà été implémenté plus largement disponible pour les sites afin qu'ils puissent l'expérimenter. Ainsi, les sites pourront faire part de leurs commentaires sur l'approche adoptée jusqu'à présent.

Qu'est-ce qu'une navigation douce ?

Nous avons donné la définition suivante d'une navigation douce:

• La navigation est lancée par une action de l'utilisateur.
• La navigation entraîne une modification de l'URL visible pour l'utilisateur et une modification de l'historique.
• La navigation entraîne une modification du DOM.

Pour certains sites, ces méthodes heuristiques peuvent donner lieu à des faux positifs (que les utilisateurs ne considéreraient pas vraiment comme une « navigation ») ou à de faux négatifs (où l'utilisateur considère qu'une « navigation » s'est produite alors qu'ils ne répondent pas à ces critères). N'hésitez pas à nous faire part de vos commentaires sur les méthodes heuristiques dans le dépôt des spécifications de la navigation logicielle.

Comment Chrome implémente-t-il la navigation logicielle ?

Une fois que les heuristiques de navigation logicielle sont activées (plus d'informations à ce sujet dans la section suivante), Chrome modifie la façon dont certaines métriques de performances sont consignées dans les rapports:

• Un événement soft-navigation PerformanceTiming est émis après chaque détection de navigation logicielle.
• L'API Performance fournira l'accès à une entrée temporelle soft-navigation, émise par l'événement PerformanceTiming soft-navigation.
• Les métriques First Paint (FP), First Contentful Paint (FCP) et LCP (Largest Contentful Paint) seront réinitialisées et réémises lors des prochaines occurrences appropriées. (Remarque: FP et FCP ne sont pas encore implémentés.)
• Un attribut navigationId sera ajouté à chacun des temps de performance (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event et layout-shift) correspondant à l'entrée de navigation à laquelle l'événement était lié, ce qui permettra de calculer les paramètres CLS (Cumulative Layout Shift) et Interaction to Next Paint (INP).

Ces modifications permettront de mesurer les métriques Core Web Vitals, ainsi que certaines métriques de diagnostic associées, en fonction de la navigation sur les pages. Toutefois, certaines nuances doivent être prises en compte.

Quelles sont les conséquences de l'activation de la navigation logicielle dans Chrome ?

Voici quelques-unes des modifications que les propriétaires de sites doivent prendre en compte après avoir activé cette fonctionnalité:

• Des événements FP, FCP et LCP supplémentaires peuvent être réémis pour les navigations douces. Le rapport d'expérience utilisateur Chrome ignore ces valeurs supplémentaires, mais cela peut affecter toute surveillance RUM (Real User Measurement) sur votre site. Contactez votre fournisseur de RUM si vous n'êtes pas sûr que cela aura un impact sur ces mesures. Consultez la section sur la mesure des Core Web Vitals pour les navigations douces.
• Le nouvel attribut navigationID (et facultatif) dans vos entrées de performances devra peut-être être pris en compte dans le code de votre application à l'aide de ces entrées.
• Seuls les navigateurs basés sur Chromium sont compatibles avec ce nouveau mode. Bien que la plupart des métriques les plus récentes ne soient disponibles que dans les navigateurs basés sur Chromium, certaines (FCP, LCP) le sont dans d'autres navigateurs, et il est possible que certains ne soient pas passés à la dernière version des navigateurs basés sur Chromium. Sachez donc que certains utilisateurs ne fournissent pas de métriques de navigation logicielle.
• En tant que nouvelle fonctionnalité expérimentale qui n'est pas activée par défaut, les sites doivent la tester pour s'assurer qu'elle n'a aucun autre effet secondaire inattendu.

Pour savoir comment mesurer les métriques pour les navigations douces, consultez la section Mesurer les Core Web Vitals par navigation logicielle.

Comment activer la navigation logicielle dans Chrome ?

Les navigations logicielles ne sont pas activées par défaut dans Chrome, mais vous pouvez les expérimenter dans Chrome 110 en activant explicitement cette fonctionnalité.

Les développeurs peuvent activer cette fonctionnalité en activant l'option Experimental Web Platform features (Fonctionnalités expérimentales de la plate-forme Web) sur chrome://flags/#enable-experimental-web-platform-features ou en utilisant l'argument de ligne de commande --enable-experimental-web-platform-features lors du lancement de Chrome.

Si un site Web souhaite activer cette fonctionnalité pour tous ses visiteurs afin de voir l'impact, il existe une phase d'évaluation exécutée à partir de Chrome 117. Pour l'activer, inscrivez-vous à l'essai et incluez un méta-élément avec le jeton de la phase d'évaluation dans l'en-tête HTML ou HTTP. Pour en savoir plus, consultez l'article Premiers pas avec les phases d'évaluation.

Les propriétaires de sites peuvent choisir d'inclure la phase d'évaluation sur leurs pages pour tous les utilisateurs ou seulement pour une partie d'entre eux. Prenez connaissance de la section Conséquences précédente pour savoir comment cela modifie la façon dont vos métriques peuvent être présentées dans les rapports, en particulier si vous activez cette phase d'évaluation pour une grande partie de vos utilisateurs. Notez que CrUX continuera de générer des rapports sur les métriques de la manière existante, quel que soit le paramètre de navigation logicielle, et qu'il n'est donc pas affecté par ces conséquences. Notez également que les phases d'évaluation se limitent à activer des fonctionnalités expérimentales sur 0,5% au maximum de tous les chargements de pages Chrome (en moyenne sur 14 jours), mais cela ne devrait poser problème que pour les sites très volumineux.

Comment mesurer les navigations douces ?

Une fois le test activé, les métriques seront générées à l'aide de l'API PerformanceObserver, comme d'habitude. Cependant, d'autres considérations doivent être prises en compte pour ces métriques.

Signaler des navigations logicielles

Vous pouvez utiliser un PerformanceObserver pour observer les navigations logicielles. Voici un exemple d'extrait de code qui consigne les entrées de navigation logicielle dans la console, y compris les navigations logicielles précédentes sur cette page avec l'option buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Cela permet de finaliser les métriques complètes de la page pour la navigation précédente.

Générer des rapports sur les métriques par rapport à l'URL appropriée

Étant donné que les navigations logicielles ne sont visibles qu'après avoir eu lieu, certaines métriques devront être finalisées au moment de cet événement, puis signalées pour l'URL précédente, car l'URL actuelle reflète désormais l'URL mise à jour pour la nouvelle page.

L'attribut navigationId du PerformanceEntry approprié peut être utilisé pour lier l'événement à l'URL appropriée. Vous pouvez le rechercher avec l'API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Ce pageUrl doit être utilisé pour générer des rapports sur les métriques par rapport à l'URL appropriée, plutôt qu'à l'URL actuelle qu'ils ont peut-être utilisée par le passé.

Obtenir le startTime des navigations logicielles

Vous pouvez obtenir l'heure de début de la navigation de la même manière:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime correspond à l'heure de l'interaction initiale (par exemple, un clic sur un bouton) qui a lancé la navigation logicielle.

Toutes les durées de performance, y compris celles des navigations douces, sont indiquées en tant que durée à partir du temps de navigation initiale "matérielle". Par conséquent, le temps de démarrage de la navigation logicielle est nécessaire pour référencer les temps des métriques de chargement de la navigation logicielle (par exemple, le LCP), par rapport à ce temps.

Mesurer les Core Web Vitals par navigation logicielle

Pour inclure des entrées de métriques de navigation logicielle, vous devez inclure includeSoftNavigationObservations: true dans l'appel observe de votre observateur de performances.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

L'indicateur includeSoftNavigationObservations supplémentaire de la méthode observe est nécessaire en plus d'activer la fonctionnalité de navigation douce dans Chrome. Cette activation explicite au niveau de l'observateur de performances permet de s'assurer que les observateurs de performances existants ne sont pas surpris par ces entrées supplémentaires. En effet, certains éléments supplémentaires doivent être pris en compte lorsque vous essayez de mesurer les Core Web Vitals pour les navigations logicielles.

Les codes temporels sont tout de même renvoyés par rapport à l'heure de début de la navigation difficile d'origine. Ainsi, pour calculer le LCP d'une navigation logicielle par exemple, vous devez prendre la durée LCP et soustraire l'heure de début de la navigation logicielle appropriée, comme expliqué précédemment, afin d'obtenir une durée par rapport à la navigation logicielle. Par exemple, pour le LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

En règle générale, certaines métriques sont mesurées tout au long de la vie d'une page: le LCP, par exemple, peut changer jusqu'à ce qu'une interaction se produise. Le CLS et l'INP peuvent être mis à jour jusqu'à ce que la page quitte la page. Par conséquent, chaque "navigation" (y compris la navigation d'origine) devra peut-être finaliser les métriques de la page précédente à mesure que chaque nouvelle navigation logicielle se produit. Cela signifie que les métriques initiales de navigation difficile peuvent être finalisées plus tôt que d'habitude.

De même, lorsque vous commencez à mesurer les métriques pour la nouvelle navigation logicielle de ces métriques de longue durée, les métriques doivent être "réinitialiser" ou "réinitialisées" et traitées comme de nouvelles métriques, sans mémoire des valeurs définies pour les "pages précédentes".

Comment traiter le contenu qui reste identique d'une navigation à l'autre ?

FP, FCP et LCP pour les navigations douces ne mesureront que les nouvelles couleurs. Cela peut entraîner un LCP différent, par exemple, d'un chargement à froid de cette navigation douce à un chargement partiel.

Prenons l'exemple d'une page qui contient une grande image de bannière qui correspond à l'élément LCP, mais que le texte situé en dessous change à chaque navigation logicielle. Le chargement initial de la page marquera l'image de bannière comme élément LCP et basera la durée LCP sur cet élément. Pour les navigations réactives ultérieures, le texte sous-jacent sera le plus grand élément peint après la navigation douce et constituera le nouvel élément LCP. Toutefois, si une nouvelle page est chargée avec un lien profond dans l'URL de navigation douce, l'image de la bannière sera un nouveau rendu et pourra donc être considérée comme l'élément LCP.

Comme le montre cet exemple, l'élément LCP de la navigation douce peut être indiqué différemment selon le mode de chargement de la page. De la même manière que le chargement d'une page avec un lien d'ancrage plus bas sur la page peut entraîner un autre élément LCP.

Comment mesurer le TTFB ?

Pour un chargement de page classique, le délai du premier octet (TTFB) représente le temps auquel les premiers octets de la requête d'origine sont renvoyés.

Pour une navigation douce, c'est une question plus délicate. Devons-nous mesurer la première demande effectuée pour la nouvelle page ? Que se passe-t-il si tout le contenu existe déjà dans l'application et qu'il n'y a pas d'autres demandes ? Que se passe-t-il si cette requête est effectuée à l'avance avec un préchargement ? Que se passe-t-il si une demande n'est pas liée à la navigation douce du point de vue de l'utilisateur (par exemple, il s'agit d'une demande d'analyse) ?

Une méthode plus simple consiste à indiquer un TTFB de 0 pour les navigations logicielles, de la même manière que pour les restaurations du cache amélioré. Il s'agit de la méthode actuellement utilisée par la bibliothèque web-vitals pour les navigations logicielles.

À l'avenir, il est possible que nous prenions en charge des moyens plus précis d'identifier la requête de navigation de la navigation douce et nous serons en mesure d'obtenir des mesures TTFB plus précises. Mais cela ne fait pas partie du test actuel.

Comment mesurer les anciens et nouveaux ?

Au cours de ce test, nous vous recommandons de continuer à mesurer vos Core Web Vitals de manière actuelle, en fonction des navigations difficiles sur les pages, afin de correspondre à l'ensemble de données officiel de l'initiative Core Web Vitals.

La navigation logicielle doit être mesurée en plus de ces éléments pour vous permettre de voir comment elles pourraient l'être à l'avenir et pour vous permettre de fournir des commentaires à l'équipe Chrome sur le fonctionnement pratique de cette implémentation. Cela vous aidera, vous et l'équipe Chrome, à façonner l'API à l'avenir.

Pour mesurer les deux, vous devez connaître les nouveaux événements qui peuvent être émis en mode navigation douce (par exemple, plusieurs événements FCP et LCP supplémentaires), et les gérer de manière appropriée en finalisant ces métriques au bon moment, tout en ignorant les événements futurs qui ne s'appliquent qu'à la navigation logicielle.

Utilisez la bibliothèque web-vitals afin de mesurer les Core Web Vitals pour les navigations douces.

Le moyen le plus simple de tenir compte de toutes ces nuances consiste à utiliser la bibliothèque JavaScript web-vitals, qui offre une compatibilité expérimentale avec les navigations douces dans un soft-navs branch distinct (également disponible sur npm et unpkg). Vous pouvez mesurer cette valeur de la manière suivante (en remplaçant doTraditionalProcessing et doSoftNavProcessing selon le cas):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Assurez-vous que les métriques sont signalées par rapport à la bonne URL, comme indiqué précédemment.

La bibliothèque web-vitals fournit les métriques suivantes pour les navigations logicielles:

Ces changements seront-ils intégrés aux mesures des métriques Core Web Vitals ?

C'est exactement ce que propose cette expérience de navigation logicielle. Nous voulons évaluer les méthodes heuristiques afin de déterminer si elles reflètent plus précisément l'expérience utilisateur avant de décider si elles seront intégrées au projet Core Web Vitals. Nous sommes ravis de l'éventualité de ce test, mais nous ne pouvons pas garantir qu'il remplacera les mesures actuelles ou à quel moment.

Nous accordons une grande importance aux commentaires des développeurs Web sur le test, aux méthodes heuristiques utilisées et aux résultats que vous jugez plus pertinents. Le dépôt GitHub de navigation logicielle est le meilleur endroit pour transmettre vos commentaires. Toutefois, les bugs individuels liés à l'implémentation dans Chrome doivent être signalés dans l'outil de suivi des problèmes Chrome.

Comment les navigations logicielles sont-elles signalées dans CrUX ?

Il reste encore à déterminer comment les navigations douces seront signalées dans CrUX si ce test aboutit. Elles ne seront pas nécessairement traitées de la même manière que les navigations "difficiles" actuelles.

Sur certaines pages Web, la navigation douce est presque identique au chargement d'une page complète en ce qui concerne l'utilisateur. L'utilisation de la technologie d'application monopage n'est qu'un détail d'implémentation. Dans d'autres, elles s'apparentent davantage à un chargement partiel de contenu supplémentaire.

Par conséquent, nous pouvons décider de les signaler séparément dans CrUX, ou éventuellement de les pondérer lors du calcul des Core Web Vitals pour une page ou un groupe de pages donnés. À mesure que l'heuristique évolue, nous pouvons aussi exclure complètement la navigation douce avec chargement partiel.

À l'heure actuelle, l'équipe se concentre sur la mise en œuvre heuristique et technique, qui nous permettra d'évaluer la réussite de ce test. Aucune décision n'a donc été prise sur ces aspects.

Commentaires

Nous sollicitons activement des commentaires sur cette expérience aux endroits suivants:

• Heuristiques et standardisation de la navigation douce.
• Problèmes d'implémentation dans Chrome de ces méthodes heuristiques.
• Commentaires d'ordre général sur Web Vitals à l'adresse web-vitals-feedback@googlegrouops.com

Journal des modifications

Cette API étant en phase de test, elle a subi un certain nombre de modifications, plus souvent qu'avec des API stables. Pour en savoir plus, consultez le journal des modifications Heuristics de navigation souple.

Conclusion

L'expérience soft navigations est une approche intéressante de la façon dont l'initiative Core Web Vitals pourrait évoluer afin de mesurer un modèle commun sur le Web moderne qui manque actuellement dans nos métriques. Ce test n'en est qu'à ses débuts (et il reste encore beaucoup à faire), mais il est important de mettre les progrès réalisés jusqu'ici à la disposition de l'ensemble de la communauté Web pour qu'ils puissent le tester. La collecte des commentaires est un autre aspect crucial du test. Nous encourageons donc vivement les personnes qui s'y intéressent à profiter de cette opportunité pour nous aider à façonner l'API et à nous assurer qu'elle est représentative de ce que nous espérons pouvoir mesurer grâce à cette fonctionnalité.

Remerciements

Vignette de Jordan Madrid sur Unsplash