Tester la mesure des navigations douces

Barry Pollard

Yoav Weiss

Mise à jour d'août 2024:le deuxième test Origin Trail pour la navigation fluide s'est terminé le 29 mai. L'équipe Chrome prend le temps d'examiner les commentaires de l'expérience et d'envisager les prochaines étapes pour cette API. Nous souhaitons résoudre certains problèmes de précision et pensons qu'un autre test d'origine sera nécessaire avant que la fonctionnalité ne soit prête à passer à l'étape suivante. En attendant, les développeurs peuvent toujours tester la fonctionnalité en activant chrome://flags/#enable-experimental-web-platform-features.

Depuis son lancement, l'initiative Core Web Vitals vise à mesurer l'expérience utilisateur réelle d'un site Web, plutôt que les détails techniques de sa création ou de son chargement. Les trois métriques Core Web Vitals ont été créées en tant que métriques centrées sur l'utilisateur, une évolution des métriques techniques existantes telles que DOMContentLoaded ou load, qui mesuraient des délais souvent sans rapport avec la façon dont les utilisateurs percevaient les performances de la page. Par conséquent, la technologie utilisée pour créer le site ne doit pas avoir d'incidence sur le score, à condition que le site fonctionne correctement.

La réalité est toujours un peu plus complexe que 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. Plutôt que de charger des pages Web distinctes et individuelles à mesure que l'utilisateur navigue sur le site, ces applications Web utilisent des "navigations douces", où 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 insérant les URL précédentes dans l'historique du navigateur pour permettre aux boutons "Précédent" et "Suivant" de fonctionner comme l'utilisateur s'y attend.

De nombreux frameworks JavaScript utilisent ce modèle, mais chacun d'eux d'une manière différente. Comme cela ne correspond pas à ce que le navigateur considère traditionnellement comme une "page", la mesure de ces éléments a toujours été difficile: où tracer la ligne entre une interaction sur la page actuelle et la considérer comme une nouvelle page ?

L'équipe Chrome réfléchit à ce problème depuis un certain temps et cherche à normaliser la définition de la "navigation fluide" et la façon dont les Core Web Vitals peuvent être mesurés à cet égard, de la même manière que les sites Web implémentés dans l'architecture multipage (MPA) classique. Bien que nous en soyons encore aux premiers stades, 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 le tester. Cela permettra aux sites de donner leur avis sur l'approche suivie jusqu'à présent.

Qu'est-ce qu'une navigation douce ?

Nous avons défini la navigation fluide comme suit:

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

Pour certains sites, ces heuristiques peuvent entraîner des faux positifs (les utilisateurs ne considéreraient pas vraiment qu'une "navigation" a eu lieu) ou des faux négatifs (l'utilisateur considère qu'une "navigation" a eu lieu alors qu'il ne remplit pas ces critères). N'hésitez pas à nous faire part de vos commentaires sur les heuristiques dans le dépôt de spécifications de la navigation fluide.

Comment Chrome implémente-t-il les navigations douces ?

Une fois les heuristiques de navigation douce activées (voir la section suivante), Chrome modifie la manière dont il présente certaines métriques de performances:

• Un événement soft-navigation PerformanceTiming est émis après chaque navigation douce détectée.
• L'API Performances fournit un accès à une entrée de chronométrage soft-navigation, telle qu'elle est émise par l'événement PerformanceTiming soft-navigation.
• Les métriques First Paint (FP) (Premier rendu), First Contentful Paint (FCP) (Premier rendu de contenu) et Largest Contentful Paint (LCP) (Plus grand rendu de contenu) seront réinitialisées et réenvoyées lors des prochaines occurrences appropriées. (Remarque: FP et FCP ne sont pas implémentés.)
• Un attribut navigationId sera ajouté à chacun des délais de performances (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 associé, ce qui permettra de calculer le déplacement cumulé de la mise en page (CLS) et l'interaction avant la prochaine peinture (INP).

Ces modifications permettront de mesurer les Core Web Vitals (et certaines des métriques de diagnostic associées) par navigation sur les pages, mais certaines nuances doivent être prises en compte.

Quelles sont les conséquences de l'activation des navigations douces 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 ignorera ces valeurs supplémentaires, mais cela peut affecter la surveillance de la mesure de l'expérience utilisateur réelle (RUM) sur votre site. Si vous avez des doutes, contactez votre fournisseur de RUM pour savoir si cela aura un impact sur ces mesures. Consultez la section sur la mesure des Core Web Vitals pour les navigations douces.
• Vous devrez peut-être tenir compte du nouvel attribut navigationID (facultatif) dans le code de votre application qui utilise ces entrées.
• Seuls les navigateurs basés sur Chromium seront compatibles avec ce nouveau mode. Bien que de nombreuses métriques plus récentes ne soient disponibles que dans les navigateurs Chromium, certaines (FCP, LCP) le sont dans les autres navigateurs. De plus, il est possible que tous les utilisateurs n'aient pas encore migré vers la dernière version des navigateurs Chromium. Sachez donc que certains utilisateurs ne signalent pas les métriques de navigation fluide.
• Il s'agit d'une nouvelle fonctionnalité expérimentale qui n'est pas activée par défaut. Les sites doivent donc la tester pour s'assurer qu'elle n'a pas d'autres effets secondaires involontaires.

Pour en savoir plus sur la mesure des métriques pour les navigations douces, consultez la section Mesurer les métriques Core Web Vitals par navigation douce.

Comment activer la navigation douce dans Chrome ?

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

Pour les développeurs, vous pouvez activer cette fonctionnalité en activant l'option Experimental Web Platform features (Fonctionnalités expérimentales de la plate-forme Web) à chrome://flags/#enable-experimental-web-platform-features ou en utilisant l'argument de ligne de commande --enable-experimental-web-platform-features au moment du lancement de Chrome.

Comment mesurer les navigations douces ?

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

Remarque : FP et FCP ne sont pas encore signalés pour les navigations douces.

Signaler les navigations douces

Vous pouvez utiliser un PerformanceObserver pour observer les navigations douces. Vous trouverez ci-dessous un exemple d'extrait de code qui consigne les entrées de navigation douce dans la console, y compris les navigations douces précédentes sur cette page à l'aide de l'option buffered:

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

Cela permet de finaliser les métriques de la page sur toute sa durée de vie pour la navigation précédente.

Créer des rapports sur les métriques pour l'URL appropriée

Comme les navigations douces ne sont visibles qu'après leur occurrence, certaines métriques doivent être finalisées lors de cet événement, puis enregistrées pour l'URL précédente, car l'URL actuelle reflètera désormais l'URL mise à jour de la nouvelle page.

L'attribut navigationId de l'PerformanceEntry approprié peut être utilisé pour associer l'événement à la bonne URL. Vous pouvez le rechercher à l'aide de 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;

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

Obtenir l'startTime des navigations douces

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 déclenché la navigation fluide.

Tous les temps de performance, y compris ceux pour les navigations douces, sont indiqués en temps à partir de la navigation initiale "dure" sur la page. Par conséquent, l'heure de début de la navigation fluide est nécessaire pour définir les temps de chargement des métriques de navigation fluide (par exemple, le LCP) par rapport à cette heure de navigation fluide.

Mesurer les Core Web Vitals par navigation fluide

Pour inclure des entrées de métrique de navigation douce, 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});

Le flag includeSoftNavigationObservations supplémentaire sur la méthode observe est nécessaire en plus de l'activation de la fonctionnalité de navigation fluide dans Chrome. Cette activation explicite au niveau de l'observateur de performances vise à s'assurer que les observateurs de performances existants ne sont pas surpris par ces entrées supplémentaires, car certains éléments supplémentaires doivent être pris en compte lorsque vous essayez de mesurer les Core Web Vitals pour les navigations douces.

Les temps de navigation sont toujours renvoyés en fonction de l'heure de début de navigation "stricte" d'origine. Par exemple, pour calculer le LCP d'une navigation fluide, vous devez prendre le temps du LCP et soustraire le temps de début de la navigation fluide approprié, comme indiqué précédemment, pour obtenir un temps par rapport à la navigation fluide. 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});

Certaines métriques étaient traditionnellement mesurées tout au long de la durée de vie de la 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 l'utilisateur quitte la page. Par conséquent, chaque "navigation" (y compris la navigation d'origine) peut être amenée à finaliser les métriques de la page précédente à chaque nouvelle navigation douce. Cela signifie que les métriques de navigation "dures" initiales peuvent être finalisées plus tôt que d'habitude.

De même, lorsque vous commencez à mesurer les métriques pour la nouvelle navigation douce de ces métriques à long terme, vous devez les "réinitialiser" ou "réinitialiser" et les traiter comme de nouvelles métriques, sans aucune mémoire des valeurs définies pour les "pages" précédentes.

Comment traiter le contenu qui reste le même entre les navigations ?

Les métriques FP, FCP et LCP pour les navigations fluides ne mesurent que les nouvelles peintures. Cela peut entraîner un LCP différent, par exemple, d'une charge à froid de cette navigation douce à une charge à froid.

Prenons l'exemple d'une page qui comprend une grande bannière qui est l'élément LCP, mais dont le texte en dessous change à chaque navigation fluide. Le chargement initial de la page marquera l'image de la bannière comme élément LCP et basera le timing LCP sur celle-ci. Pour les navigations ultérieures, le texte en dessous sera le plus grand élément peint après la navigation fluide et sera 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 une nouvelle peinture et pourra donc être considérée comme l'élément LCP.

Comme le montre cet exemple, l'élément LCP de la navigation fluide peut être comptabilisé différemment en fonction de la façon dont la page est chargée. De même, le chargement d'une page avec un lien d'ancrage plus bas sur la page peut entraîner un élément LCP différent.

Comment mesurer le délai avant réponse ?

Le temps avant le premier octet (TTFB) d'un chargement de page classique correspond au moment où les premiers octets de la requête d'origine sont renvoyés.

Pour une navigation douce, cette question est plus délicate. Devrions-nous mesurer la première requête envoyée pour la nouvelle page ? Que se passe-t-il si tous les contenus existent déjà dans l'application et qu'il n'y a pas de requêtes supplémentaires ? 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 requête n'est pas liée à la navigation fluide du point de vue de l'utilisateur (par exemple, s'il s'agit d'une requête d'analyse) ?

Une méthode plus simple consiste à indiquer un TTFB de 0 pour les navigations douces, comme nous le recommandons pour les restaurations du cache avant/arrière. C'est la méthode utilisée par la bibliothèque web-vitals pour les navigations douces.

À l'avenir, nous pourrons proposer des méthodes plus précises pour déterminer quelle requête est la "requête de navigation" de la navigation fluide et nous pourrons mesurer le TTFB plus précisément. Mais cela ne fait pas partie du test en cours.

Comment mesurer les deux ?

Pendant ce test, nous vous recommandons de continuer à mesurer vos Core Web Vitals de la manière actuelle, en fonction des navigations sur les pages "dures", afin qu'elles correspondent à ce que CrUX mesurera et rapportera en tant qu'ensemble de données officiel de l'initiative Core Web Vitals.

Les navigations douces doivent être mesurées en plus de ces éléments pour vous permettre de voir comment elles pourraient être mesurées à l'avenir et pour vous donner l'occasion de faire part de vos commentaires à l'équipe Chrome sur le fonctionnement de cette implémentation dans la pratique. Cela vous aidera, ainsi que l'équipe Chrome, à façonner l'API à l'avenir.

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

Utiliser la bibliothèque web-vitals pour mesurer les Core Web Vitals pour les navigations douces

Le moyen le plus simple de prendre en compte toutes les nuances consiste à utiliser la bibliothèque JavaScript web-vitals, qui est compatible avec la navigation douce expérimentale dans un soft-navs branch distinct (également disponible sur npm et unpkg). Vous pouvez mesurer cela de la manière suivante (en remplaçant doTraditionalProcessing et doSoftNavProcessing selon les besoins):

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 enregistrées avec l'URL correcte, comme indiqué précédemment.

La bibliothèque web-vitals enregistre les métriques suivantes pour les navigations douces:

Métrique	Détails
TTFB	Valeur indiquée : 0.
FCP	Seul le premier FCP de la page est enregistré.
LCP	Heure de la prochaine plus grande peinture de contenu, par rapport au début de la navigation fluide. Les peintures existantes de la navigation précédente ne sont pas prises en compte. Par conséquent, la LCP sera >= 0. Comme d'habitude, cela sera signalé lors d'une interaction ou lorsque la page sera en arrière-plan, car seul le LCP peut être finalisé.
CLS	Plage de décalage la plus longue entre les heures de navigation. Comme d'habitude, cela se produit lorsque la page est exécutée en arrière-plan, car le CLS ne peut être finalisé que dans ce cas. Si aucun décalage n'est appliqué, la valeur 0 est renvoyée.
INP	INP entre les temps de navigation. Comme d'habitude, cela sera signalé lors d'une interaction ou lorsque la page sera en arrière-plan, car ce n'est qu'à ce moment-là que l'INP peut être finalisé. Aucune valeur 0 n'est enregistrée en l'absence d'interactions.

Avertissement:L'implémentation de web-vitals est en cours de développement et est susceptible d'être modifiée, car de nouvelles modifications sont publiées dans cette branche. Il n'est pas compatible avec le FCP pour les navigations douces, car cela nécessite plus de travail sous-jacent dans Chrome. Les utilisateurs de la bibliothèque JavaScript web-vitals doivent en tenir compte s'ils souhaitent l'utiliser sur des sites de production. Ils doivent créer une copie locale et tester cette version, et surveiller la branche pour détecter les modifications.

Ces modifications feront-elles partie des mesures Core Web Vitals ?

Ce test de navigation douce n'est qu'un test. Nous souhaitons évaluer les heuristiques et déterminer si elles reflètent plus précisément l'expérience utilisateur avant de prendre une décision concernant leur intégration dans l'initiative Core Web Vitals. Nous sommes très enthousiastes à l'idée de pouvoir tester cette fonctionnalité, mais nous ne pouvons pas garantir qu'elle remplacera les mesures actuelles et quand cela se produira.

Nous apprécions les commentaires des développeurs Web sur le test, les heuristiques utilisées et si, selon vous, il reflète plus précisément l'expérience. Le dépôt GitHub de la navigation fluide est le meilleur endroit pour envoyer ces commentaires, mais les bugs individuels liés à l'implémentation de cette fonctionnalité dans Chrome doivent être signalés dans le outil de suivi des problèmes Chrome.

Comment les navigations douces seront-elles enregistrées dans CrUX ?

La manière exacte dont les navigations douces seront enregistrées dans CrUX, si ce test est un succès, reste également à déterminer. Il n'est pas nécessairement certain qu'elles seront traitées de la même manière que les navigations "dures" actuelles.

Sur certaines pages Web, la navigation douce est presque identique à la page complète chargée pour l'utilisateur, et l'utilisation de la technologie d'application monopage n'est qu'un détail d'implémentation. Dans d'autres cas, il peut s'agir d'une charge partielle de contenu supplémentaire.

Nous pouvons donc décider de les enregistrer séparément dans CrUX ou de les pondérer lors du calcul des Core Web Vitals pour une page ou un groupe de pages donnés. Nous pourrons peut-être également exclure complètement la navigation douce à chargement partiel à mesure que l'heuristique évoluera.

L'équipe se concentre sur l'implémentation heuristique et technique, qui nous permettra de juger du succès de ce test. Aucune décision n'a donc été prise à ce sujet.

Commentaires

Nous recherchons activement vos commentaires sur ce test sur les pages suivantes:

• Heuristiques et standardisation des navigations douces
• Problèmes d'implémentation de Chrome de ces heuristiques.
• Pour envoyer des commentaires généraux sur les Core Web Vitals, envoyez un e-mail à [e-mail].

Journal des modifications

Comme cette API est en phase d'expérimentation, elle est soumise à un certain nombre de modifications, plus que les API stables. Pour en savoir plus, consultez le journal des modifications des heuristiques de navigation douce.

Conclusion

L'expérimentation sur les navigations fluides est une approche intéressante pour voir comment l'initiative Core Web Vitals pourrait évoluer afin de mesurer un modèle courant sur le Web moderne qui est absent de nos métriques. Ce test n'en est qu'à ses débuts, et il reste encore beaucoup à faire. Toutefois, il est important de rendre les progrès réalisés jusqu'à présent disponibles pour la communauté Web plus large. La collecte des commentaires de ce test est également essentielle. Nous encourageons donc vivement les personnes intéressées par ce développement à saisir cette opportunité pour contribuer à façonner l'API afin qu'elle soit représentative de ce que nous espérons pouvoir mesurer avec elle.

Remerciements

Image miniature par Jordan Madrid sur Unsplash