Tester la mesure des navigations douces

Barry Pollard

Yoav Weiss

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. Pour cette raison, la technologie utilisée pour créer le site ne doit pas avoir d'incidence sur la notation, si le site est performant.

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 au fur et à mesure que l'utilisateur parcourt le site, ces applications Web utilisent ce que l'on appelle des "navigations logicielles", dans lesquelles le contenu de la page est modifié par JavaScript. Dans ces applications, l'illusion d'une architecture de page Web conventionnelle est préservée 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 l'utilisateur s'y attend.

De nombreux frameworks JavaScript utilisent ce modèle, mais chacun d'eux d'une manière différente. Ces données ne correspondant pas à ce que le navigateur interprète traditionnellement comme une "page", il a toujours été difficile de les mesurer: où doit-on séparer une interaction sur la page actuelle par rapport à la considérer comme une nouvelle page ?

L'équipe Chrome s'intéresse à ce défi depuis un certain temps, et cherche à standardiser une définition de la "navigation souple" et à déterminer comment mesurer les métriques Core Web Vitals, de la même manière que les sites Web implémentés dans l'architecture multipage conventionnelle. 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 les tester. Les sites pourront ainsi donner leur avis sur l'approche adoptée jusqu'à présent.

Qu'est-ce qu'une navigation logicielle ?

Nous avons défini la navigation fluide comme suit :

• 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 DOM.

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

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

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 Performance donne accès à une entrée de durée 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 métriques Core Web Vitals et certaines métriques de diagnostic associées par navigation sur les pages. Toutefois, il existe des nuances à prendre 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 effectuer 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. 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 savoir comment mesurer les métriques associées aux navigations logicielles, consultez la section Mesurer les Core Web Vitals par navigation approximative.

Comment activer la navigation fluide dans Chrome ?

Les navigations douces ne sont pas activées par défaut dans Chrome, mais peuvent faire l'objet de tests en les activant explicitement.

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.

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.

Signaler les navigations douces

Vous pouvez utiliser un PerformanceObserver pour observer les navigations douces. Voici un exemple d'extrait de code qui enregistre les entrées de navigation logicielle dans la console, y compris les navigations logicielles 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 });

Vous pouvez l'utiliser pour 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

Étant donné que les navigations logicielles ne sont visibles qu'après leur survenue, certaines métriques devront être finalisées lors de cet événement, puis enregistrées pour l'URL précédente. En effet, l'URL actuelle reflète désormais l'URL mise à jour pour la nouvelle page.

L'attribut navigationId de l'PerformanceEntry approprié peut être utilisé pour associer l'événement à la bonne URL. Pour cela, utilisez 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 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 est l'heure de l'interaction initiale (par exemple, un clic sur un bouton) ayant déclenché la navigation logicielle.

Tous les temps de performances, 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 de la métrique 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});

Vous devez ajouter l'indicateur includeSoftNavigationObservations à la méthode observe en plus d'activer la fonctionnalité de navigation logicielle 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 avoir besoin de finaliser les métriques de la page précédente à chaque nouvelle navigation logicielle. 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 pour la navigation logicielle peut être signalé différemment selon le mode de chargement de la page. De la même manière que charger une page avec un lien d'ancrage plus bas peut générer un élément LCP différent.

Comment mesurer le délai avant réponse ?

Le délai avant le premier octet (TTFB) pour un chargement de page classique représente le délai de renvoi des premiers octets de la requête d'origine.

Pour une navigation douce, c'est une question plus délicate. Devrions-nous mesurer la première requête envoyé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 requête n'est pas liée à la navigation logicielle du point de vue de l'utilisateur (par exemple, s'il s'agit d'une demande 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, il se peut que nous prenions en charge des moyens plus précis de savoir quelle requête est la "requête de navigation" de la navigation logicielle et nous pourrons avoir des mesures TTFB plus précises. 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 comme suit (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 :

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 logicielle est presque identique au chargement de la page entière du point de vue de l'utilisateur. L'utilisation de la technologie d'application monopage n'est qu'un détail d'implémentation. Dans d'autres, il peut s'agir d'un chargement partiel de contenu supplémentaire.

Par conséquent, nous pouvons décider de comptabiliser ces navigations logicielles séparément dans l'expérience utilisateur Chrome (CrUX) ou de les pondérer lors du calcul des métriques Core Web Vitals pour une page ou un groupe de pages donnés. Il se peut également que nous puissions complètement exclure la navigation partielle à chargement partiel à mesure que l'heuristique évolue.

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 sur ces deux points.

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 à l'adresse web-vitals-feedback@googlegroups.com.

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 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