Tester la mesure des navigations douces

Barry Pollard

Michal Mocny

Publié le 1er février 2023, dernière mise à jour le 22 juillet 2025

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 liés à sa création ou à son chargement. Les trois métriques Core Web Vitals ont été créées en tant que métriques centrées sur l'utilisateur. Elles représentent une évolution par rapport aux 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 devrait pas avoir d'incidence sur le score, à condition que le site soit 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 compatible avec les métriques Core Web Vitals. Au lieu de charger des pages Web distinctes et individuelles lorsque 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 conventionnelle 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 à sa manière. Comme cela ne correspond pas à ce que le navigateur considère traditionnellement comme une "page", il a toujours été difficile de mesurer cela : où faut-il tracer la limite entre une interaction sur la page actuelle et une interaction sur une nouvelle page ?

L'équipe Chrome réfléchit à ce défi depuis un certain temps et cherche à standardiser une définition de ce qu'est une "navigation logicielle" et à déterminer comment mesurer les métriques Core Web Vitals pour ce type de navigation, de la même manière que pour les sites Web implémentés dans l'architecture multipage (MPA) conventionnelle.

Nous avons travaillé dur pour améliorer l'API depuis le dernier test d'origine. Nous demandons maintenant aux développeurs d'essayer la dernière itération et de nous faire part de leurs commentaires sur l'approche avant son lancement.

Qu'est-ce qu'une navigation logicielle ?

Nous avons défini la navigation logicielle comme suit :

• La navigation est lancée par une action de l'utilisateur.
• La navigation entraîne une modification visible de l'URL pour l'utilisateur et une modification 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 (les utilisateurs considéreraient qu'une "navigation" a eu lieu même si elle ne répond 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 logicielle.

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

Une fois les heuristiques de navigation logicielle activées (nous y reviendrons dans la section suivante), Chrome modifiera la façon dont il génère certains rapports sur les performances :

• Un événement soft-navigation PerformanceTiming est émis chaque fois qu'une navigation réversible est détectée.
• Un nouvel interaction-contentful-paint sera émis après les interactions qui entraînent un affichage significatif. Cela peut être utilisé pour mesurer le Largest Contentful Paint (LCP) pour les navigations douces lorsqu'une telle peinture s'étend sur une navigation douce. Notez que l'implémentation d'origine de cette réinitialisation permettait de réémettre la métrique largest-contentful-paint. Nous avons opté pour cette autre approche par souci de simplicité, mais aussi pour une plus grande marge de manœuvre à l'avenir.
• Un attribut navigationId sera ajouté à chacun des temps de performances (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event et layout-shift) correspondant à l'entrée de navigation à laquelle l'événement était associé. Cela permettra de calculer et d'attribuer le Largest Contentful Paint (LCP), le Cumulative Layout Shift (CLS) et l'Interaction to Next Paint (INP) à la bonne URL.

Ces modifications permettront de mesurer les Core Web Vitals et certaines des métriques de diagnostic associées par navigation sur les pages. Toutefois, il convient de tenir compte de certaines nuances.

Quelles sont les implications de l'activation des navigations douces dans Chrome ?

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

• Les métriques CLS et INP peuvent être segmentées par URL de navigation douce, plutôt que mesurées sur la durée de vie complète de la page.
• L'entrée largest-contentul-paint étant déjà finalisée lors d'une interaction, elle n'est utilisée que pour mesurer le premier temps de chargement de la plus grande image ou du plus grand élément de contenu visible (LCP) de navigation "dure". Aucune logique supplémentaire n'est donc nécessaire pour modifier la façon dont elle est mesurée.
• La nouvelle métrique interaction-contentful-paint sera émise à partir des interactions, qui pourront être utilisées pour mesurer le LCP pour les navigations douces.
• Pour attribuer les navigations douces à la bonne URL, il peut être nécessaire de prendre en compte le nouvel attribut navigationID de vos entrées de performances dans le code de votre application à l'aide de ces entrées.
• Tous les utilisateurs ne seront pas compatibles avec cette API de navigation logicielle, en particulier ceux qui utilisent d'anciennes versions de Chrome ou d'autres navigateurs. Sachez que certains utilisateurs peuvent ne pas signaler les métriques de navigation logicielle, même s'ils signalent les métriques Core Web Vitals.
• Cette nouvelle fonctionnalité expérimentale n'étant pas activée par défaut, les sites doivent la tester pour détecter d'éventuels effets secondaires indésirables.

Contactez votre fournisseur RUM pour savoir s'il permet de mesurer les Core Web Vitals par navigation logicielle. De nombreux éditeurs prévoient de tester cette nouvelle norme et tiendront compte des considérations précédentes. En attendant, certains fournisseurs autorisent également des mesures limitées des métriques de performances basées sur leurs propres heuristiques.

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

Comment activer les navigations douces 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, cette fonctionnalité peut être activée en activant le flag Experimental Web Platform features (Fonctionnalités expérimentales de la plate-forme Web) sur chrome://flags/#soft-navigation-heuristics ou en utilisant les arguments de ligne de commande --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution lors du lancement de Chrome.

Un site Web qui souhaite activer cette fonctionnalité pour tous ses visiteurs afin d'en évaluer l'impact peut participer à une phase d'évaluation des origines à partir de Chrome 139. Pour ce faire, il doit s'inscrire à la phase d'évaluation et inclure un élément meta avec le jeton de la phase d'évaluation des origines dans l'en-tête HTML ou HTTP. Pour en savoir plus, consultez l'article Premiers pas avec les versions d'essai d'origine.

Les propriétaires de sites peuvent choisir d'inclure l'essai d'origine sur leurs pages pour tous les utilisateurs ou seulement pour un sous-ensemble d'entre eux. Tenez compte des implications précédentes concernant la façon dont vos métriques peuvent être signalées, en particulier si vous activez cet essai d'origine pour une grande partie de vos utilisateurs. Notez que CrUX continuera de générer des rapports sur les métriques de la même manière, quel que soit ce paramètre de navigation logicielle. Il n'est donc pas concerné par ces implications. Il convient également de noter que les versions d'essai des origines sont également limitées à l'activation de fonctionnalités expérimentales sur un maximum de 0,5 % de toutes les pages Chrome chargées (médiane sur 14 jours). Toutefois, cela ne devrait poser problème qu'aux très grands sites.

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 les autres métriques. Toutefois, il faut tenir compte de certains éléments supplémentaires 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 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 peut être utilisé pour finaliser les métriques de page "durée de vie complète" pour la navigation précédente.

Signaler les métriques par rapport à l'URL appropriée

Étant donné que les navigations douces ne peuvent être observées qu'après leur occurrence, certaines métriques devront être finalisées lors de cet événement, puis signalé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 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 signaler les métriques par rapport à la bonne URL, plutôt que l'URL actuelle qu'ils ont pu utiliser par le passé.

Obtenir le startTime des navigations douces

L'heure de début de la navigation peut être obtenue 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 douce.

Tous les temps de performances, y compris ceux des navigations douces, sont indiqués comme un temps écoulé depuis le temps de navigation "dure" initial sur la page. Par conséquent, l'heure de début de la navigation logicielle est nécessaire pour établir une référence pour les temps de chargement des métriques de navigation logicielle (par exemple, le LCP), par rapport à cette heure de navigation logicielle.

Mesurer les Core Web Vitals par navigation logicielle

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

Avec les dernières modifications apportées à l'API, l'indicateur includeSoftNavigationObservations n'est plus nécessaire et sera probablement supprimé à l'avenir. Toutefois, pour l'instant, cette activation explicite au niveau de l'observateur de performances est requise en plus de l'activation de la fonctionnalité de navigation douce dans Chrome.

Les timings seront toujours renvoyés par rapport à l'heure de début de la navigation "dure" d'origine. Ainsi, pour calculer le LCP d'une navigation logicielle, par exemple, vous devrez prendre le timing interaction-contentful-paint et soustraire l'heure de début de la navigation logicielle appropriée, comme détaillé précédemment, pour obtenir un timing relatif à la navigation logicielle. Par exemple, pour 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Certaines métriques ont toujours été mesurées tout au long de la durée de vie de la page. Par exemple, la métrique LCP peut changer jusqu'à ce qu'une interaction se produise. Vous pouvez mettre à jour le CLS et l'INP tant que vous n'avez pas quitté 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 "dure" initiales 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, elles devront être "réinitialisées" ou "réinitialisées" et traitées comme de nouvelles métriques, sans mémoire des valeurs qui ont été définies pour les "pages" précédentes.

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

La valeur LCP pour les navigations douces (calculée à partir de interaction-contentful-paint) ne mesurera que les nouvelles peintures. Cela peut entraîner un LCP différent, par exemple, entre un chargement à froid de cette navigation logicielle et un chargement logiciel.

Par exemple, prenons une page qui inclut une grande bannière d'image qui est l'élément LCP, mais dont le texte situé en dessous change à chaque navigation douce. Lors du chargement initial de la page, l'image de la bannière sera signalée comme élément LCP et le timing LCP sera basé sur celle-ci. Pour les navigations douces suivantes, le texte ci-dessous sera le plus grand élément affiché après la navigation douce et deviendra le nouvel élément LCP. Toutefois, si une nouvelle page est chargée avec un lien profond vers l'URL de navigation logicielle, 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 la façon dont la page est chargée. De la même manière, 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 TTFB ?

Le temps de latence du premier octet (TTFB) pour un chargement de page classique représente le temps nécessaire pour renvoyer les premiers octets de la requête d'origine.

Pour une navigation fluide, la question est plus délicate. Devons-nous mesurer la première requête 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 de demandes supplémentaires ? Que se passe-t-il si cette requête est effectuée à l'avance avec une prélecture ? Que se passe-t-il si une requête n'est pas liée à la navigation douce 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 à signaler un TTFB de 0 pour les navigations douces, de la même manière que nous le 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 douces.

À l'avenir, nous pourrons peut-être identifier plus précisément la "demande de navigation" d'une navigation douce et obtenir des mesures TTFB plus précises. Mais cela ne fait pas partie de l'implémentation actuelle.

Comment mesurer les anciennes et les nouvelles données ?

Pendant ce test, nous vous recommandons de continuer à mesurer vos métriques Core Web Vitals de la manière habituelle, en fonction des navigations de page "dures", pour qu'elles correspondent à ce que CrUX mesurera et indiquera en tant qu'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 faire part de vos commentaires à l'équipe Chrome sur le fonctionnement de cette implémentation en pratique. Cela vous aidera, vous et l'équipe Chrome, à façonner l'API à l'avenir.

Pour le LCP, cela signifie qu'il faut tenir compte uniquement des entrées largest-contentful-paint pour l'ancienne méthode, et des entrées largest-contentful-paint et interaction-contentful-paint pour la nouvelle méthode.

Pour le CLS et l'INP, cela signifie qu'il faut les mesurer sur l'ensemble du cycle de vie de la page, comme c'était le cas auparavant, et segmenter séparément la timeline par navigation douce pour mesurer des valeurs CLS et INP distinctes pour la nouvelle méthode.

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

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

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 associées à la bonne URL, 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 fluide est exactement cela : un test. Nous souhaitons évaluer les heuristiques et voir si elles reflètent plus précisément l'expérience utilisateur avant de décider de les intégrer ou non à l'initiative Core Web Vitals. Nous sommes très enthousiastes à l'idée de ce test, mais nous ne pouvons pas garantir si ni quand il remplacera les mesures actuelles.

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

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

Si ce test est concluant, nous devrons également déterminer comment les navigations douces seront exactement signalées dans CrUX. Il n'est pas certain qu'elles soient traitées de la même manière que les navigations "dures" actuelles.

Sur certaines pages Web, les navigations douces sont presque identiques aux chargements de page complets du point de vue de l'utilisateur, et l'utilisation de la technologie d'application monopage n'est qu'un détail d'implémentation. Dans d'autres, ils peuvent s'apparenter davantage à une charge partielle de contenu supplémentaire.

Nous pouvons donc décider de signaler ces navigations douces séparément dans CrUX, ou peut-être de les pondérer lors du calcul des statistiques Web essentielles pour une page ou un groupe de pages donnés. Nous pourrons peut-être aussi exclure complètement la navigation logicielle à chargement partiel, à mesure que l'heuristique évoluera.

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

Commentaires

Nous recueillons activement vos commentaires sur ce test aux endroits suivants :

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

Journal des modifications

Comme cette API est en phase expérimentale, elle subit de nombreuses modifications, plus que les API stables. Pour en savoir plus, consultez le journal des modifications des heuristiques de navigation logicielle.

Conclusion

L'expérience de navigation douce est une approche intéressante pour l'évolution de l'initiative Core Web Vitals, qui pourrait permettre de mesurer un modèle courant sur le Web moderne qui manque à nos métriques. Bien que ce test n'en soit qu'à ses débuts et qu'il reste encore beaucoup à faire, il est important de mettre les progrès réalisés jusqu'à présent à la disposition de la communauté Web au sens large pour qu'elle puisse les tester. Recueillir les commentaires de ce test est une autre partie cruciale de l'expérience. Nous encourageons donc vivement les personnes intéressées par ce développement à profiter de cette occasion pour contribuer à façonner l'API afin de s'assurer qu'elle représente ce que nous espérons pouvoir mesurer avec elle.

Remerciements

Vignette de Jordan Madrid sur Unsplash

Ce travail fait suite à celui initié par Yoav Weiss lorsqu'il travaillait chez Google. Nous remercions Yoav pour ses efforts concernant cette API.