Tester la mesure des navigations douces

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 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 aux métriques techniques existantes, telles que DOMContentLoaded ou load, qui mesuraient des délais souvent sans lien 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 délicate que l'idéal, et l'architecture populaire des applications monopages n'a jamais été entièrement compatible avec 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'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. L'équipe n'en est qu'à ses débuts, mais elle est désormais prête à étendre la portée de ce qui a déjà été mis en œuvre aux sites, afin qu'ils puissent l'expérimenter. Les sites pourront ainsi donner leur avis sur l'approche adoptée jusqu'à présent.

Qu'est-ce qu'une navigation logicielle ?

Voici la définition d'une navigation logicielle:

  • 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 douce sur les méthodes heuristiques.

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

Une fois que l'heuristique de navigation logicielle est activée (vous trouverez plus d'informations à ce sujet dans la section suivante), Chrome modifiera la façon dont certaines métriques de performances sont présentées:

  • Un événement soft-navigation PerformanceTiming sera émis après chaque détection de navigation logicielle.
  • 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), First Contentful Paint (FCP) et Largest Contentful Paint (LCP) seront réinitialisées et renvoyées lors des prochaines occurrences appropriées. (Remarque: FP et FCP ne sont pas implémentés.)
  • Un attribut navigationId sera ajouté à chacune des durées d'exécution (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 permet de calculer cumul Layout Shift (CLS) et Interaction to Next Paint (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.

Que se passe-t-il si vous activez la navigation logicielle dans Chrome ?

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

  • D'autres événements FP, FCP et LCP peuvent être réémis pour les navigations logicielles. Le rapport sur l'expérience utilisateur Chrome (CrUX) ignore ces valeurs supplémentaires, mais cela peut avoir un impact sur le suivi de la métrique "Real User Measurement" (RUM) sur votre site. Contactez votre fournisseur RUM si vous avez des doutes sur l'impact de ces mesures sur ces mesures. Consultez la section Mesurer les Core Web Vitals pour les navigations logicielles.
  • Vous devrez peut-être intégrer le nouvel attribut navigationID (et facultatif) dans vos entrées relatives aux performances 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 nouvelles métriques ne soient disponibles que dans les navigateurs basés sur Chromium, certaines (FCP, LCP) le sont également dans d'autres navigateurs. Il est donc possible que tout le monde n'ait pas installé la dernière version des navigateurs basés sur Chromium. Sachez que certains utilisateurs peuvent ne pas générer de rapports sur les métriques de navigation flexible.
  • Comme il s'agit d'une 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 pas d'autres effets indésirables.

Pour savoir comment mesurer les métriques associées aux navigations logicielles, consultez la section Mesurer les Core Web Vitals par navigation logicielle.

Comment activer la navigation logicielle dans Chrome ?

Les navigations douces ne sont pas activées par défaut dans Chrome, mais vous pouvez faire des 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 logicielles ?

Une fois le test des navigations logicielles activé, les métriques seront enregistrées à l'aide de l'API PerformanceObserver comme d'habitude. Toutefois, vous devez tenir compte de certains points supplémentaires pour ces métriques.

Signaler les navigations logicielles

Vous pouvez utiliser un PerformanceObserver pour observer les navigations logicielles. 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 });

Cela permet de finaliser les métriques sur l'intégralité de la page pour la navigation précédente.

Créer des rapports sur les métriques par rapport à 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 du PerformanceEntry approprié peut être utilisé pour lier l'événement à l'URL appropriée. 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;

Ce pageUrl doit être utilisé pour générer un rapport sur les métriques par rapport à l'URL appropriée, plutôt qu'à l'URL actuelle qu'il aurait pu utiliser 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.

Toutes les durées des performances, y compris celles des navigations souples, sont indiquées en tant que temps écoulé depuis la date de début "difficile" le temps de navigation sur les pages. Par conséquent, le temps de début de la navigation flexible est nécessaire pour référencer les temps de chargement des métriques de navigation flexible (par exemple, le LCP) par rapport à ce temps de navigation flexible.

Mesurer les Core Web Vitals par navigation logicielle

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

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 des performances permet de s'assurer que les observateurs de performances existants ne sont pas surpris par ces entrées supplémentaires. En effet, il faut tenir compte de certains éléments supplémentaires lorsqu'ils tentent de mesurer les Core Web Vitals pour les navigations douces.

Les codes temporels seront toujours renvoyés par rapport à la date "difficile" d'origine. l'heure de début de la navigation. Par exemple, pour calculer le LCP d'une navigation flexible, vous devez prendre le temps LCP et soustraire le temps de démarrage approprié de la navigation flexible, comme détaillé précédemment, afin d'obtenir un temps relatif à la navigation flexible. 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 sont généralement mesurées tout au long de la durée de vie de la page. Par exemple, le LCP peut changer jusqu'à ce qu'une interaction se produise. Le CLS et l'INP peuvent être mis à jour jusqu'à ce que vous quittiez la page. Ainsi, 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 la phase initiale "difficile" les métriques de navigation peuvent être finalisées plus tôt que d'habitude.

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

Comment traiter un contenu qui reste identique entre les navigations ?

FP, FCP et LCP pour la navigation flexible ne mesureront que les nouvelles peintures. Cela peut entraîner un LCP différent, par exemple d'une charge à froid de cette navigation flexible à une charge partielle.

Prenons l'exemple d'une page qui inclut une grande image de bannière qui constitue l'élément LCP, mais que le texte en dessous change à chaque navigation logicielle. Le chargement initial de la page marque l'image de bannière comme élément LCP et base le temps LCP sur celui-ci. Pour les navigations douces ultérieures, le texte en dessous sera le plus grand élément peint après la navigation flexible et constituera le nouvel élément LCP. Toutefois, si une nouvelle page est chargée avec un lien profond vers l'URL de navigation flexible, l'image de bannière sera une nouvelle couleur 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. Tout comme le chargement d'une page avec un lien d'ancrage plus bas peut générer un élément LCP différent.

Comment mesurer le TTFB ?

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. 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 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 à signaler le TTFB de 0 pour les navigations logicielles, de la même manière que nous recommandons pour les restaurations du cache amélioré. Il s'agit de la méthode utilisée par la bibliothèque web-vitals pour les navigations logicielles.

À l'avenir, il se peut que nous prenions en charge des moyens plus précis d'identifier la requête correspondant à la "requête de navigation" de la navigation logicielle. et pourra avoir des mesures TTF1 plus précises. Mais cela ne fait pas partie du test actuel.

Comment mesurer les anciennes et les nouvelles fonctionnalités ?

Pendant ce test, nous vous recommandons de continuer à mesurer vos Core Web Vitals de la manière actuelle, en fonction de la métrique "difficile" navigations sur les pages pour correspondre à ce que CrUX mesurera et consignera comme ensemble de données officiel de l'initiative Core Web Vitals.

Les navigations douces doivent être mesurées en plus de celles-ci pour vous permettre de voir comment elles pourraient être mesurées à l'avenir et pour vous donner l'occasion 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 ces deux éléments, vous devez connaître les nouveaux événements qui peuvent être émis en mode de navigation flexible (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'aux navigations douces.

Utiliser la bibliothèque web-vitals afin de mesurer les métriques Core Web Vitals pour les navigations logicielles

Le moyen le plus simple de prendre en compte toutes les nuances consiste à utiliser la bibliothèque JavaScript web-vitals, qui offre une compatibilité expérimentale pour les navigations douces dans un fichier soft-navs branch distinct (également disponible sur npm et unpkg). Vous pouvez mesurer cela comme suit (en remplaçant doTraditionalProcessing et doSoftNavProcessing, le cas échéant):

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 pour la bonne URL, comme indiqué précédemment.

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

Métrique Détails
TTFB Signalé en tant que 0.
FCP Seul le premier FCP de la page est indiqué.
LCP Heure du prochain élément Contentful Paint par rapport au moment de début de la navigation flexible. Les peintures existantes provenant de la navigation précédente ne sont pas prises en compte. Par conséquent, le LCP sera supérieur ou égal à 0. Comme d'habitude, ces informations sont signalées lors d'une interaction ou lorsque la page est mise en arrière-plan, car c'est à ce moment-là que le LCP peut être finalisé.
CLS La plus grande fenêtre de décalages entre les temps de navigation. Comme d'habitude, lorsque la page est mise en arrière-plan, c'est à ce moment-là que le CLS peut être finalisé. La valeur 0 est indiquée en l'absence de décalages.
INP INP entre les heures de navigation. Comme d'habitude, cette information est signalée lors d'une interaction ou lorsque la page est mise en arrière-plan, car c'est à ce moment-là que l'INP peut être finalisé. La valeur 0 n'est pas indiquée en l'absence d'interactions.

Ces changements feront-ils partie des mesures Core Web Vitals ?

Il s'agit exactement d'un test de la navigation logicielle. Nous souhaitons évaluer les méthodes heuristiques et déterminer si elles reflètent plus précisément l'expérience utilisateur avant de décider si elles seront intégrées à l'initiative Core Web Vitals. Nous sommes très enthousiastes à l'idée de réaliser ce test, mais nous ne pouvons pas garantir avec certitude s'il remplacera ou non les mesures actuelles.

Nous valorisons les développeurs Web des commentaires sur le test, l'heuristique utilisée et si vous pensez qu'il reflète plus précisément l'expérience. Le dépôt GitHub de navigation logicielle est le meilleur endroit pour envoyer ces commentaires. Toutefois, les bugs individuels liés à l'implémentation de Chrome qui doivent être signalés dans l'outil de suivi des problèmes Chrome.

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

Il reste également à déterminer comment les navigations exactes seront signalées dans CrUX si ce test est réussi. Il n'est pas forcément garanti qu'ils soient traités de la même manière que les modèles "difficiles" actuels. et les navigations sont traitées.

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 signaler ces navigations douces séparément dans l'expérience utilisateur 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 aussi exclure complètement la navigation partielle à chargement partiel à mesure que l'heuristique évolue.

L'équipe se concentre sur l'implémentation heuristique et technique, ce qui nous permettra d'évaluer la réussite de cette expérience. Aucune décision n'a donc été prise à ce sujet.

Commentaires

Nous sollicitons activement votre avis sur cette expérience aux emplacements suivants:

Journal des modifications

Comme cette API est en phase de test, un certain nombre de modifications y sont apportées, bien plus qu'avec des API stables. Pour en savoir plus, consultez le journal de modifications de l'heuristique de navigation douce.

Conclusion

Le test des navigations douces est une approche intéressante de la manière dont l'initiative Core Web Vitals pourrait évoluer pour mesurer un modèle commun sur le Web moderne, qui ne figure pas dans nos métriques. Bien que ce test en soit encore à ses débuts et qu'il reste encore beaucoup à faire, il est important de mettre les progrès réalisés à la disposition de l'ensemble de la communauté Web pour qu'elle puisse les tester. Recueillir les commentaires issus de ce test constitue un autre aspect crucial du test. Par conséquent, nous encourageons vivement les personnes intéressées par ce développement à profiter de cette opportunité pour contribuer à façonner l'API et s'assurer qu'elle est représentative de ce que nous espérons pouvoir mesurer grâce à cette expérience.

Remerciements

Miniature de Jordan Madrid sur Unsplash