Mesurer les navigations douces

Barry Pollard

Michal Mocny

Publié le 1er février 2023, dernière mise à jour le 24 juin 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 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 d'application monopage populaire n'a jamais été entièrement compatible avec les métriques des 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 ce type d'interaction. 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. Elle cherche à normaliser une définition de ce qu'est une "navigation logicielle" et à déterminer comment les Core Web Vitals peuvent être mesurés pour cela, 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 nous prévoyons de déployer deux nouvelles API de performances pour résoudre ce problème à partir de Chrome 151.

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.
• L'interaction entraîne un affichage visible.

Pour certains sites, cette définition peut 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 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 compatibilité avec les navigations douces au panneau "Performances" des outils de développement dans la vue Trace :

Vous pouvez voir des repères pour les navigations douces et le LCP, tous deux marqués d'un * pour les différencier des entrées de navigation dures habituelles. Cette fonctionnalité est activée par défaut et est distincte des modifications apportées à l'API de performances que nous aborderons ensuite. C'est un moyen rapide de vérifier si la détection des navigations douces fonctionne correctement pour votre site.

Pour l'instant, seuls les codes temporels de navigation logicielle et LCP s'affichent dans la vue Trace. D'autres métriques (par exemple, le LCP) et la prise en charge dans la vue Métriques en direct seront ajoutées ultérieurement.

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 génère les rapports sur certaines métriques de performances :

• Un événement soft-navigation PerformanceTiming est émis chaque fois qu'une navigation réversible est détectée.
• 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 une première peinture avec 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é à chacun des timings de 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 Signaler les métriques pour l'URL appropriée.
• Le soft-navigation inclura une fonction getLargestInteractionContentfulPaint() pour récupérer la plus grande entrée interaction-contentful-paint pour cette navigation. Cette valeur peut ensuite être utilisée comme LCP initial pour cette navigation, puis être mise à jour à mesure que d'autres entrées interaction-contentful-paint pour cette interaction sont observées. Notez que cela remplace un attribut largestInteractionContentfulPaint disponible dans les versions d'évaluation de l'origine précédentes.
• Il est possible que certaines entrées interaction-contentful-paint se soient produites avant la navigation logicielle (si la mise à jour de l'URL n'a lieu qu'après ces peintures). Dans ce cas, la fonction getLargestInteractionContentfulPaint() évite d'avoir à mettre en mémoire tampon et à revenir sur les anciennes entrées une fois la navigation logicielle terminé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. Il est donc possible que cette entrée ait utilisé le navigationId précédent, car c'est à ce moment-là que la peinture a eu lieu. Toutefois, ces peintures doivent être mesurées par rapport au nouveau navigationId.
• L'entrée soft-navigation inclura également paintTime et presentationTime comme FCP pour cette navigation.
• Notez que des 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 également uniquement aux propriétés largestContentfulPaint dans cette 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é :

• La surveillance des entrées soft-navigation permet de "découper" les entrées de performances dans 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 la durée de vie complète de la page. Toutefois, la fonctionnalité de navigation fluide 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 logicielle). Elle ne peut donc être utilisée que pour mesurer le LCP de la navigation "dure" initiale. Cela signifie que cette valeur ne changera pas lorsque les navigations douces seront mesurées. La valeur LCP pour le chargement de page initial et dur pourra donc être mesurée comme avant.
• 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 à l'intérieur. Toutefois, il existe certaines considérations concernant l'utilisation de cette entrée que nous aborderons dans cet article.
• Notez que tous les utilisateurs ne pourront pas utiliser cette fonctionnalité de navigation fluide, 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 basées sur la navigation logicielle, même s'ils signalent les métriques Core Web Vitals.

Vérifiez auprès de votre fournisseur RUM 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 ?

La fonctionnalité de navigation douce devrait être activée par défaut dans Chrome 151, mais vous pouvez la tester avant en l'activant explicitement.

Pour les développeurs, cette fonctionnalité peut être activée en activant l'indicateur à l'adresse chrome://flags/#soft-navigation-heuristics. Vous pouvez également l'activer à l'aide des arguments de ligne de commande --enable-features=SoftNavigationHeuristics lorsque vous lancez Chrome. L'activation de l'indicateur chrome://flags/#enable-experimental-web-platform-features active également les navigations douces.

Certains propriétaires de sites Web l'ont également activé sur leurs sites avant le lancement, grâce au processus d'essai Origin Trial. Sachez que la forme de l'API a changé tout au long du développement de la fonctionnalité et que la fonctionnalité finale diffère des précédentes versions d'évaluation (Origin Trial), comme indiqué dans le journal des modifications des navigations douces.

Détecter la compatibilité de 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
}

Notez que supportedEntryTypes est figé lors de la première utilisation. Par conséquent, si la prise en charge des navigations douces est ajoutée de manière dynamique par un jeton d'essai d'origine injecté dans la page, cette propriété peut renvoyer la valeur d'origine, avant l'activation de cette fonctionnalité.

Dans ce cas, vous pouvez utiliser l'alternative suivante tant que les navigations douces ne sont pas encore prises en charge par défaut et sont dans cet état de transition :

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

Comment mesurer les navigations douces ?

Une fois la détection des navigations douces activée, 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 points 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 complète pour la navigation précédente.

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

Lorsqu'une navigation douce est détectée, les Core Web Vitals de la page précédente doivent être finalisés, puis signalés pour l'URL précédente. Une nouvelle surveillance doit ensuite ê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 signalées, et navigationId sera la référence unique pour cette navigation (car la même URL peut être visitée plusieurs fois au cours de la durée de vie d'une application monopage).

Cette valeur doit être définie pour chaque entrée soft-navigation et utilisée pour générer des rapports sur les métriques jusqu'à ce que l'entrée soft-navigation suivante soit reçue.

Signaler l'URL correcte pour interaction-contentful-paint

Des considérations supplémentaires sont nécessaires pour calculer le temps LCP à partir des entrées interaction-contentful-paint, car toutes les entrées interaction-contentful-paint ne doivent pas être mappées à l'aide de navigationId et signalées comme temps LCP pour cette URL :

• Le premier problème est que les entrées interaction-contentful-paint peuvent être émises avant la navigation logicielle si une peinture se produit avant la mise à jour de l'URL. Dans ce cas, le navigationId concernera l'ancienne URL. Si l'URL est mise à jour en premier, la peinture termine la navigation logicielle. Dans ce cas, l'entrée soft-navigation est émise en premier et l'entrée interaction-contentful-paint contient la nouvelle URL.
• Le deuxième problème est que, à partir de interaction-contentful-paint, des entrées 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 tenir compte que des peintures pour le chargement de la navigation logicielle pour le LCP, et non de celles pour les interactions ultérieures.

Par conséquent, c'est le interactionId et non le navigationId qui doit être utilisé pour mapper les entrées interaction-contentful-paint sur soft-navigation-entries afin d'obtenir la bonne URL. Cela gérera toutes les entrées avec d'anciennes valeurs navigationId et filtrera toutes les entrées interaction-contentful-paint qui ne doivent pas être prises en compte pour le LCP.

De plus, vous devez envisager de traiter la fonction getLargestInteractionContentfulPaint() des entrées soft-navigation afin de gérer plus facilement les entrées interaction-contentful-paint qui se produisent avant l'émission de soft-navigation entries.

Obtenir le startTime des navigations douces

Tous les temps de performances, y compris ceux des navigations douces, et les entrées utilisées pour calculer les métriques Core Web Vitals sont indiqués comme un temps écoulé depuis le temps de navigation "dure" initiale sur la page. Par conséquent, le temps de début de la navigation logicielle doit être soustrait des temps de métriques de chargement de la navigation logicielle (par exemple, le temps LCP) pour les signaler par rapport à ce temps de navigation logicielle.

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. C'est un peu différent des "navigations dures", où le "temps de début" correspond au moment où la nouvelle page est "validée" par le navigateur, après l'exécution d'une partie du code du gestionnaire d'événements. Les temps de démarrage de la navigation logicielle incluent également ce code de gestionnaire d'événements, car nous effectuons les mesures à partir du temps de démarrage de l'interaction.

Mesurer les Core Web Vitals par navigation logicielle

Pour mesurer les Core Web Vitals, écoutez les entrées soft-navigation et réinitialisez les métriques à la réception de celles-ci. Le FCP peut être émis en fonction de l'entrée presentationTime et le LCP peut être initialisé sur l'entrée getLargestInteractionContentfulPaint(). L'INP et le CLS doivent être initialisés sur 0, comme ils 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, qui fournit les correspondances interactionId). Le interactionId peut être utilisé pour nommer les entrées d'une URL, comme vu précédemment.

Les timings seront toujours renvoyés par rapport à l'heure de début de navigation "dure" d'origine. Ainsi, pour calculer le LCP d'une navigation douce, par exemple, vous devrez prendre le timing interaction-contentful-paint et soustraire l'heure de début de la navigation douce appropriée, comme détaillé précédemment, pour obtenir un timing relatif à la navigation douce.

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. 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 "dure" initiales peuvent être finalisées plus tôt que d'habitude lorsque vous mesurez les métriques Core Web Vitals avec des navigations douces.

De même, lorsque vous commencerez à mesurer les métriques pour la nouvelle navigation fluide de ces métriques de longue durée, vous devrez les "réinitialiser" ou les "réinitialiser" et les traiter comme de nouvelles métriques, sans tenir compte des valeurs définies pour les "pages" précédentes. En d'autres termes, la compréhension de ce que sont 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 nouvelles peintures et uniquement celles associées à l'interaction qui a provoqué la navigation. Cela peut entraîner un LCP différent, par exemple, entre un chargement à froid et un chargement à chaud de cette navigation logicielle.

Prenons l'exemple d'une page qui inclut une grande image de bannière qui est l'élément LCP, mais dont le texte situé en dessous change à chaque navigation logicielle. Lors du chargement de page initial, l'image de 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 la page est chargée avec un lien profond vers l'URL de navigation logicielle, l'image de bannière sera une nouvelle peinture 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 éventuelle navigation douce. Les nouveaux affichages dus à cette animation d'arrière-plan ne seraient pas pris en compte dans le temps LCP pour la nouvelle navigation fluide. Toutefois, ils peuvent être pris en compte pour le LCP si la page a été rechargé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, le chargement d'une page avec un lien d'ancrage plus bas sur la page peut entraîner un élément LCP différent pour les navigations matérielles.

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 logicielle, 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 à partir du cache Back/Forward. Il s'agit de la méthode utilisée par la bibliothèque web-vitals pour les navigations douces, et celle que nous recommandons pour cette métrique pour le moment.

Dois-je mesurer les métriques Core Web Vitals avec les deux méthodologies ?

Bien que ces nouvelles API soient limitées aux navigateurs basés sur Chromium, les sites peuvent souhaiter mesurer les deux en segmentant par navigation logicielle et en continuant à segmenter par navigation matérielle. Cela permettrait de comparer les données entre les navigateurs et d'analyser les tendances historiques.

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

Pour le CLS et l'INP, cela signifie que nous les mesurons sur l'ensemble du cycle de vie de la page, comme c'est le cas actuellement, et que nous segmentons séparément la timeline par navigation douce pour mesurer des valeurs CLS et INP distinctes pour la nouvelle.

Les métriques devraient ensuite être signalées et stockées deux fois pour analyse.

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 est d'utiliser la bibliothèque JavaScript web-vitals, qui offre une compatibilité expérimentale avec les 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 le cas échéant) :

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 vous permet également de vous assurer que les métriques sont signalées par rapport à la bonne URL 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 feront-elles partie des mesures Core Web Vitals ?

L'objectif final est de fournir un moyen de mieux mesurer les performances telles qu'elles sont vécues 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.

Nous apprécions les commentaires des développeurs Web sur l'API et sur la question de savoir si elle 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 de Chrome.

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

La façon exacte dont les navigations douces seront signalées dans CrUX, une fois la fonctionnalité lancée, reste également à déterminer. Nous vous informerons des changements apportés à CrUX dès que nous aurons plus d'informations à vous communiquer.

Commentaires

Nous sollicitons activement vos commentaires sur cette API aux endroits 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.
• Pour nous faire part de vos commentaires généraux sur les signaux Web essentiels, envoyez un e-mail à l'adresse web-vitals-feedback@googlegroups.com.

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

Journal des modifications

Cette API a subi de nombreuses modifications au cours de son développement, plus que les API stables. Pour en savoir plus, consultez le journal des modifications des navigations douces.

Conclusion

La fonctionnalité de navigation logicielle est une approche intéressante pour l'évolution de l'initiative Core Web Vitals. Elle permet de mesurer un modèle courant sur le Web moderne qui n'est pas pris en compte dans nos métriques. Nous avons recueilli de nombreux commentaires de la part de la communauté Web au sens large. Nous encourageons vivement les personnes intéressées par ce développement à profiter de cette occasion pour contribuer à façonner les API afin de s'assurer qu'elles représentent ce que nous espérons pouvoir mesurer avec elles.

Remerciements

Vignette de 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 concernant cette API.