Tester la mesure des navigations douces

Barry Pollard

Michal Mocny

Publié le 1er février 2023, dernière mise à jour le 30 mars 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 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 Core Web Vitals 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 à l'API en fonction des commentaires des développeurs lors de la dernière version d'essai d'origine. Nous demandons maintenant aux développeurs de tester la dernière itération et de nous faire part de leurs commentaires sur l'approche avant son lancement. Nous sommes assez confiants quant à l'état actuel de l'API après ces itérations et prévoyons de la lancer plus tard cette année, en fonction des commentaires reçus lors de ce dernier test d'origine.

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, 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 ces critères ne sont pas remplis). 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.

Compatibilité de DevTools avec les navigations douces

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. Il s'agit d'un moyen rapide de tester si l'expérience de navigation fluide fonctionne correctement pour votre site.

Pour l'instant, seuls les codes temporels de navigation logicielle et de 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 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.
• 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 peinture avec contenu. Il peut être utilisé pour mesurer le Largest Contentful Paint (LCP) pour les navigations douces lorsque l'interaction émet une navigation douce.
• 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.
• soft-navigation inclura une entrée largestInteractionContentfulPaint, y compris la plus grande entrée interaction-contentful-paint émise lors de la navigation. Cette valeur peut ensuite être utilisée comme LCP initiale pour cette navigation, puis être mise à jour à mesure que d'autres entrées interaction-contentful-paint pour cette interaction sont observées.
• Il est possible que certaines entrées interaction-contentful-paint se produisent avant la navigation logicielle (si la mise à jour de l'URL n'a lieu qu'après ces peintures). Dans ce cas, l'entrée largestInteractionContentfulPaint la plus grande évite d'avoir à mettre en mémoire tampon et à revenir sur les anciennes entrées. Notez que largestInteractionContentfulPaint est une copie exacte de la plus grande entrée interaction-contentful-paint. Cette entrée aura donc 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 temps LCP d'une URL doit être limité aux entrées interaction-contentful-paint qui correspondent aux navigations douces interactionId pour les exclure.

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 entière de la page. Toutefois, l'API Soft Navigation fournit une mesure standardisée de ce qui se passe, 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 fluide). 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. Toutefois, il convient de tenir compte de certains éléments concernant l'utilisation de cette entrée, que nous aborderons dans cet article.
• Notez que 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 basées sur la navigation logicielle, même s'ils signalent les métriques Core Web Vitals.
• 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 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 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.

Pour qu'un site Web puisse activer cette fonctionnalité pour tous ses visiteurs et constater son impact, une phase d'évaluation de l'origine sera disponible à partir de Chrome 147. Pour l'activer, il suffira de s'inscrire à la phase d'évaluation et d'inclure un élément meta avec le jeton de la phase d'évaluation de l'origine 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 à 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.

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'Origin Trial 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 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, vous devez 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 "durée de vie 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 généré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). 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;

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 interaction-contentful-paint contient 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 tenir compte que des peintures pour le chargement de la navigation logicielle pour le LCP, et non celles des interactions ultérieures.

Par conséquent, c'est interactionId et non 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 l'entrée largestInteractionContentfulPaint 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 douce. C'est un peu différent des "navigations dures", où l'heure 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 la mesure à 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 lorsque vous les recevez. Le FCP peut être émis en fonction de presentationTime et le LCP peut être initialisé sur largestInteractionContentfulPaint. 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). Les interactionId et navigationId peuvent être utilisés 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 la navigation "dure" d'origine. Ainsi, pour calculer le temps 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.

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 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 définies pour les "pages" précédentes. Autrement dit, la compréhension de ce que sont la "plus grande" peinture, 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 de cette navigation logicielle et un chargement logiciel.

Prenons l'exemple d'une page qui inclut une grande bannière qui est l'élément LCP, mais dont le texte situé en dessous change à chaque navigation logicielle. Lors du chargement initial de la page, 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 la 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 fluide. Les nouvelles peintures dues à cette animation d'arrière-plan ne seraient pas prises en compte pour le LCP de 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 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 ?

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", car la nouvelle implémentation peut présenter des problèmes ou changer avant d'être déployée. Cela correspondra également à ce que mesure CrUX pour le moment (nous y reviendrons plus tard).

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 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 devons les mesurer sur l'ensemble du cycle de vie de la page, comme c'est le cas actuellement, et segmenter séparément la chronologie par navigation douce pour mesurer des valeurs CLS et INP distinctes pour la nouvelle.

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 ?

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. L'objectif final est de fournir un moyen de mieux mesurer les performances telles qu'elles sont vécues par les utilisateurs réels. Si ce test s'avère concluant, l'objectif est d'inclure ces métriques dans les mesures des signaux Web essentiels telles qu'elles sont présentées par tous les outils.

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 à un chargement partiel 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 Core Web Vitals 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 :

• 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

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

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.