Mesurer les navigations douces

Barry Pollard

Michal Mocny

Publié le 1er février 2023, dernière mise à jour le 20 septembre 2026

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 axées sur l'utilisateur. Elles constituent une évolution par rapport aux métriques techniques existantes telles que DOMContentLoaded ou load, qui mesuraient des durées 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 l'évaluation, à condition que le site soit performant.

La réalité est toujours un peu plus complexe que l'idéal, et l'architecture populaire d'application monopage n'a jamais été entièrement compatible avec les métriques Core Web Vitals. Plutôt que de charger des pages Web distinctes et individuelles lorsque l'utilisateur parcourt 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 envoyant 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. Comme cela ne correspond pas à ce que le navigateur considère traditionnellement comme une "page", il a toujours été difficile de mesurer ce phénomène : où tracer la limite entre une interaction sur la page actuelle et une interaction considérée comme une nouvelle page ?

L'équipe Chrome réfléchit à ce problème depuis un certain temps déjà et cherche à standardiser la définition d'une "navigation logicielle" et la manière dont les Core Web Vitals peuvent être mesurés pour celle-ci, de la même manière que les sites Web implémentés dans l'architecture multipage (MPA) conventionnelle sont mesurés.

Nous avons apporté plusieurs améliorations à la proposition en fonction des commentaires des développeurs et avons lancé deux nouvelles API de performances pour résoudre ce problème à partir de Chrome 151. De plus, nous avons mis à disposition les métriques de navigation logicielle dans le rapport sur l'expérience utilisateur de Chrome (CrUX) en tant que métriques expérimentales.

Qu'est-ce qu'une navigation logicielle ?

Nous avons défini la navigation douce comme suit :

• La navigation est lancée par une action de l'utilisateur.
• La navigation entraîne une modification de l'URL visible par l'utilisateur.
• L'interaction entraîne un affichage visible.

Pour certains sites, cette définition peut entraîner des faux positifs (les utilisateurs ne considèrent pas vraiment qu'une "navigation" a eu lieu) ou des faux négatifs (l'utilisateur considère qu'une "navigation" a eu lieu, même si ces critères ne sont pas remplis). N'hésitez pas à nous faire part de vos commentaires dans le dépôt de spécifications de la navigation logicielle.

Prise en charge des navigations douces dans les outils de développement

Nous avons ajouté la prise en charge des navigations douces au panneau "Performances" des outils de développement dans la vue Métriques en direct, ainsi que dans la vue de trace avec la prise en charge des insights et des repères :

Comment Chrome implémente-t-il les navigations douces pour les développeurs Web ?

Une fois la fonctionnalité de navigation logicielle activée (nous y reviendrons dans la section suivante), Chrome modifiera la façon dont il enregistre certaines métriques de performances :

• Un événement soft-navigation PerformanceTiming sera émis après la détection de chaque navigation logicielle.
• Cette entrée soft-navigation inclura un navigationId, la nouvelle URL dans l'attribut name, ainsi qu'un interactionId de l'interaction initiale.
• Une ou plusieurs entrées interaction-contentful-paint seront émises après les interactions qui entraînent un affichage du contenu. Il contiendra une entrée largestContentfulPaint qui peut être utilisée pour mesurer le Largest Contentful Paint (LCP) pour les navigations douces.
• L'attribut navigationId est ajouté à chaque chronométrage des performances (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event et layout-shift). Il correspond à l'entrée de navigation sous laquelle l'événement a été émis. Notez que lorsque ces entrées couvrent des navigations douces, elles peuvent contenir le navigationId précédent ou suivant, selon le moment où l'entrée a été émise. Pour en savoir plus, consultez la section Créer des rapports sur les métriques pour l'URL appropriée.
• soft-navigation inclura une fonction getLargestInteractionContentfulPaint() pour récupérer l'entrée interaction-contentful-paint la plus grande pour cette navigation. Il peut ensuite être utilisé comme LCP initial pour cette navigation, et ce LCP peut ensuite être mis à jour à mesure que d'autres entrées interaction-contentful-paint pour cette interaction sont observées. Notez que cela remplace l'attribut largestInteractionContentfulPaint disponible dans les précédents essais Origin Trial.
• Il est possible que certaines entrées interaction-contentful-paint aient eu lieu avant la navigation logicielle (si la mise à jour de l'URL n'a lieu qu'après ces affichages). Dans ce cas, la fonction getLargestInteractionContentfulPaint() évite d'avoir à mettre en mémoire tampon et à examiner les anciennes entrées une fois qu'une navigation logicielle est finalisée. Notez que l'entrée renvoyée par getLargestInteractionContentfulPaint() est une copie exacte de la plus grande entrée interaction-contentful-paint au moment où elle a été émise. Cette entrée peut donc avoir utilisé le navigationId précédent, car c'est à ce moment-là que la peinture a eu lieu, mais ces peintures doivent être mesurées par rapport au nouveau navigationId.
• L'entrée soft-navigation inclura également paintTime et presentationTime en tant que FCP pour cette navigation.
• Sachez que les entrées interaction-contentful-paint seront également émises après d'autres interactions, mais que le LCP d'une URL doit être limité aux entrées interaction-contentful-paint qui correspondent aux navigations douces interactionId pour les exclure, et uniquement aux propriétés largestContentfulPaint de ces entrées.

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

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

• La surveillance des entrées soft-navigation permet de "découper" les entrées de performances en chaque "navigation".
• Les métriques CLS et INP peuvent déjà être segmentées à votre discrétion, plutôt que d'être mesurées sur toute la durée du cycle de vie de la page. Toutefois, la fonctionnalité de navigation logicielle fournit une mesure standardisée du moment où cela se produit, quelle que soit la technologie sous-jacente utilisée.
• L'entrée largest-contentful-paint est finalisée lors d'une interaction (nécessaire pour démarrer une navigation douce). Elle ne peut donc être utilisée que pour mesurer le LCP de la navigation "standard" initiale. Cela signifie que cela ne changera pas lorsque les navigations douces seront mesurées. Ainsi, le LCP pour le chargement de page initial (navigation dure) pourra être mesuré comme il l'a toujours été.
• La nouvelle entrée interaction-contentful-paint qui sera émise à partir des interactions peut être utilisée pour mesurer le LCP pour les navigations douces en examinant la propriété largestContentfulPaint qu'elle contient. Toutefois, nous aborderons dans cet article quelques points à prendre en compte pour utiliser cette entrée.
• Notez que cette fonctionnalité de navigation logicielle ne sera pas compatible avec tous les utilisateurs, en particulier ceux qui utilisent d'autres navigateurs ou des versions de Chrome antérieures à la version 151. Sachez que certains utilisateurs peuvent ne pas signaler de métriques basées sur la navigation logicielle, même s'ils signalent des métriques Core Web Vitals.

Vérifiez auprès de votre fournisseur de RUM s'il est possible de mesurer les Core Web Vitals par navigation logicielle. Beaucoup d'entre eux prévoient de tester cette nouvelle norme et prendront en compte les considérations précédentes. En attendant, certains fournisseurs permettent également de mesurer de manière limitée les métriques de performances en fonction de leurs propres heuristiques.

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 les navigations douces dans Chrome ?

La fonctionnalité de navigations douces est activée par défaut à partir de Chrome 151.

Détection de la compatibilité avec l'API Soft Navigations

Vous pouvez utiliser le code suivant pour vérifier si l'API est compatible :

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Ou bien :

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Comment mesurer les navigations douces ?

Lorsqu'elles sont compatibles, les métriques peuvent être enregistrées à l'aide de l'API PerformanceObserver, comme les autres métriques. Cependant, d'autres éléments doivent être pris 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 consigne 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 peut être utilisé pour finaliser les métriques de page sur l'ensemble de la durée de vie pour la navigation précédente.

Enregistrer les métriques pour l'URL appropriée

Lorsqu'une navigation logicielle est détectée, les métriques Core Web Vitals de la page précédente doivent être finalisées, puis signalées pour l'URL précédente, et une nouvelle surveillance doit être lancée pour la nouvelle URL.

L'attribut name de l'entrée soft-navigation appropriée contiendra la nouvelle URL pour laquelle les métriques doivent être enregistrées, et navigationId sera la référence unique pour cette navigation (car une même URL peut être visitée plusieurs fois au cours de la durée de vie d'une application monopage).

Il doit être défini comme chaque entrée soft-navigation et utilisé pour générer des rapports sur les métriques jusqu'à la réception de l'entrée soft-navigation suivante.

Signaler l'URL correcte pour interaction-contentful-paint

Le calcul du LCP à partir des entrées interaction-contentful-paint nécessite des considérations supplémentaires, car toutes les entrées interaction-contentful-paint ne doivent pas être mappées à l'aide de navigationId et signalées comme LCP pour cette URL :

• Le premier problème est que les entrées interaction-contentful-paint peuvent être émises avant la navigation réactive si un paint se produit avant la mise à jour de l'URL. Dans ce cas, le navigationId correspondra à l'ancienne URL. Si l'URL est mise à jour en premier, l'affichage terminera la navigation réactive. Dans ce cas, l'entrée soft-navigation sera émise en premier, et l'entrée interaction-contentful-paint aura la nouvelle URL.
• Le deuxième problème est que les entrées interaction-contentful-paint continueront d'être émises pour les interactions plus récentes, car le champ d'application de cette métrique de performances s'étend au-delà du LCP pour les navigations douces. Nous ne voulons prendre en compte que les peintures pour le chargement de la navigation logicielle pour le LCP, et non celles pour les interactions ultérieures.

Par conséquent, vous devez utiliser interactionId plutôt que navigationId pour mapper les entrées interaction-contentful-paint à soft-navigation-entries afin d'obtenir l'URL correcte. Cela permet de gérer toutes les entrées avec d'anciens navigationId et de filtrer toutes les entrées interaction-contentful-paint qui ne doivent pas être prises en compte pour le LCP.

De plus, vous devez d'abord traiter la fonction getLargestInteractionContentfulPaint() des entrées soft-navigation pour gérer les entrées interaction-contentful-paint qui se sont produites avant l'émission de soft-navigation entries.

Obtenir le startTime des navigations douces

Toutes les mesures de performances, y compris celles des navigations douces, et les entrées utilisées pour calculer les métriques Core Web Vitals sont indiquées sous forme de durée à partir du temps de navigation initial "dur" de la page. Par conséquent, l'heure de début de la navigation douce doit être soustraite des temps de chargement de la navigation douce (par exemple, le LCP) pour les rapporter par rapport à cette heure de navigation douce.

L'heure de début de la navigation peut être obtenue de la même manière en mappant l'entrée soft-navigation appropriée et en utilisant son startTime.

startTime correspond à l'heure de l'interaction initiale (par exemple, un clic sur un bouton) qui a déclenché la navigation logicielle. Cela diffère quelque peu des "navigations complètes", où l'"heure de début" correspond au moment où la nouvelle page est "validée" dans le navigateur, et après l'exécution d'une partie du code du gestionnaire d'événements. Les heures de début de la navigation douce incluent également le code du gestionnaire d'événements, car nous mesurons à partir de l'heure de début de l'interaction.

Mesurer les métriques Core Web Vitals par navigation logicielle

Pour mesurer les Core Web Vitals, écoutez les entrées soft-navigation et réinitialisez les métriques lorsque vous les recevez. Le FCP peut être émis en fonction de presentationTime, et le LCP peut être initialisé sur l'entrée getLargestInteractionContentfulPaint(). Les métriques INP et CLS doivent être initialisées à 0, comme elles le seraient pour un chargement de page.

Le LCP, l'INP et le CLS peuvent ensuite être mesurés et surveillés comme d'habitude (à l'exception de l'utilisation de interaction-contentful-paint pour le LCP, à condition que le interactionId corresponde). interactionId peut être utilisé pour nommer les entrées d'une URL, comme indiqué précédemment.

Les codes temporels seront toujours renvoyés par rapport à l'heure de début de la navigation "matérielle" d'origine. Pour calculer le LCP d'une navigation réactive, par exemple, vous devez prendre le temps interaction-contentful-paint et soustraire l'heure de début de la navigation réactive appropriée, comme décrit précédemment, afin d'obtenir un temps relatif à la navigation réactive.

Certaines métriques sont 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, quelles que soient les interactions. Par conséquent, les métriques de la navigation précédente doivent être finalisées à chaque nouvelle navigation logicielle. Cela signifie que les métriques de navigation "hard" initiales peuvent être finalisées plus tôt que d'habitude lors de la mesure des métriques Core Web Vitals avec des navigations "soft".

De même, lorsque vous commencez à mesurer les métriques pour la nouvelle navigation logicielle de ces métriques de longue durée, elles doivent être "réinitialisées" et traitées comme de nouvelles métriques, sans mémoire des valeurs définies pour les "pages" précédentes. Autrement dit, la compréhension de ce qu'est le "plus grand" paint, l'interaction to next paint ou le décalage de mise en page est réinitialisée pour permettre une nouvelle mesure à partir de zéro.

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

Le LCP pour les navigations douces (calculé à partir de interaction-contentful-paint) ne mesurera que les nouveaux paints, et uniquement ceux associés à l'interaction qui a provoqué la navigation. Cela peut entraîner un LCP différent entre un chargement à froid de cette navigation réactive et un chargement à chaud.

Prenons l'exemple d'une page qui inclut une grande image de bannière qui est l'élément LCP, mais dont le texte en dessous change à chaque navigation logicielle. Le chargement de page initial signalera l'image de bannière comme élément LCP et basera le temps LCP sur celui-ci. Pour les navigations douces suivantes, le texte ci-dessous sera le plus grand élément peint après la navigation douce et sera le nouvel élément LCP. Toutefois, si la page est chargée avec un lien profond vers l'URL de navigation logicielle, l'image de bannière sera un nouveau paint et pourra donc être considérée comme l'élément LCP.

De même, une animation peut mettre à jour une partie de la page en continu, sans rapport avec une navigation logicielle. Les nouvelles peintures dues à cette animation d'arrière-plan ne seraient pas prises en compte pour le LCP de la nouvelle navigation logicielle. Toutefois, ils peuvent être pris en compte pour le LCP si la page a été actualisée à partir de cette URL.

Comme le montrent ces exemples, 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 que le chargement d'une page avec un lien d'ancrage plus bas dans la page peut entraîner un élément LCP différent pour les navigations matérielles.

Comment mesurer le TTFB ?

Le Time to First Byte (TTFB) pour un chargement de page classique représente le temps nécessaire pour que les premiers octets de la requête d'origine soient renvoyés.

Pour une navigation logicielle, la question est plus délicate. Doit-on 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 requêtes supplémentaires ? Que se passe-t-il si cette requête est effectuée à l'avance avec une pré-extraction ? 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 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 back/forward. Il s'agit de la méthode utilisée par la bibliothèque web-vitals pour les navigations douces et de celle que nous recommandons actuellement pour cette métrique.

Devez-vous mesurer les Core Web Vitals avec les deux méthodes ?

Bien que ces nouvelles API soient limitées aux navigateurs basés sur Chromium, les sites peuvent vouloir mesurer les deux en segmentant par navigations douces et en continuant à segmenter par navigations dures. Cela permettrait de comparer les navigateurs et les tendances historiques.

Pour le LCP, cela signifie qu'il ne faut prendre en compte que les entrées largest-contentful-paint pour la méthode actuelle, et les 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'est le cas actuellement, et diviser séparément la chronologie par navigations douces pour mesurer des valeurs CLS et INP distinctes pour la nouvelle.

Les métriques devraient alors être balisées et stockées deux fois pour l'analyse.

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 prend en charge les navigations douces à partir de la version 6.0.0. Vous pouvez mesurer cela 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';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

La bibliothèque web-vitals garantit également que vous signalez les métriques par rapport à l'URL appropriée, comme indiqué précédemment, car elles incluent à la fois navigationId et navigationURL dans les entrées fournies au rappel.

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

Ces modifications seront-elles intégrées aux mesures des métriques Core Web Vitals ?

L'objectif final est de fournir un moyen de mieux mesurer les performances telles qu'elles sont perçues par les utilisateurs réels. L'objectif est donc d'inclure ces métriques dans les mesures Core Web Vitals, telles qu'elles sont exposées par tous les outils après le lancement de l'API.

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

Nous avons lancé des versions expérimentales des métriques Core Web Vitals dans CrUX. Elles mettent fin au CLS et à l'INP de la "navigation dure" après la première navigation logicielle, et incluent également des mesures supplémentaires de LCP, CLS et INP pour chaque navigation logicielle. Nous prévoyons de faire passer ces métriques expérimentales à des métriques stables en mai 2027. Pour en savoir plus, consultez l'article de blog Experimental soft navigation metrics now available in CrUX (Métriques expérimentales de navigation logicielle désormais disponibles dans CrUX).

Comment gérer les navigations douces dans d'autres navigateurs ?

Les navigations douces sont difficiles à détecter de manière programmatique dans les navigateurs qui ne sont pas compatibles avec l'API. C'est précisément la raison pour laquelle nous avons développé cette API.

Il est possible d'utiliser l'API Navigation pour surveiller les modifications d'URL, ce qui peut permettre de segmenter l'INP par URL (et de même pour le CLS, bien qu'il ne soit disponible que sur Chromium pour le moment et ne soit donc pas mesuré). Toutefois, cela ne résout pas le problème des métriques de rendu (FCP et LCP), qui ne peuvent être qu'approximatives.

En même temps, nous pensons que les insights offerts par cette API sont trop précieux pour être ignorés, à la fois pour mesurer le timing des navigations douces et pour attribuer les métriques à la bonne navigation. Nous vous recommandons d'utiliser cette nouvelle API, même si elle n'est pas encore compatible avec tous les navigateurs. Comme lors du lancement des Core Web Vitals, les problèmes identifiés et les solutions de performances affecteront probablement tous les navigateurs, même si la visibilité est limitée aux navigateurs basés sur Chromium pour le moment.

Nous continuerons à travailler sur le processus de standardisation et à collaborer avec les autres fournisseurs de navigateurs pour montrer l'importance de cette API.

Commentaires

Nous sollicitons activement des commentaires sur cette API aux emplacements suivants :

• Les commentaires sur l'API doivent être signalés en tant que problèmes sur GitHub.
• Les bugs liés à l'implémentation de Chromium doivent être signalés dans l'outil de suivi des problèmes de Chrome, s'ils ne font pas encore partie des problèmes connus.
• Vous pouvez envoyer vos commentaires généraux sur les signaux Web essentiels à l'adresse web-vitals-feedback@googlegroups.com.

En cas de doute, ne vous inquiétez pas. Nous préférons recevoir les commentaires à l'un ou l'autre de ces endroits, et nous nous ferons un plaisir de trier les problèmes et de les rediriger vers le bon emplacement.

Journal des modifications

Au cours du développement de cette API, un certain nombre de modifications ont été apportées, plus que pour les API stables. Pour en savoir plus, consultez le journal des modifications des navigations douces.

Conclusion

La fonctionnalité de navigations douces est une approche intéressante de la façon dont l'initiative Core Web Vitals pourrait évoluer pour mesurer un modèle courant sur le Web moderne qui ne figure pas dans nos métriques. Nous avons recueilli de nombreux commentaires de la communauté Web et nous sommes encouragés par le potentiel de cette API.

Remerciements

Vignette par Jordan Madrid sur Unsplash

Ce travail s'inscrit dans la continuité de celui initié par Yoav Weiss lorsqu'il travaillait chez Google. Nous remercions Yoav pour ses efforts sur cette API.