Dernière phase d'évaluation des navigations douces à partir de Chrome 147

Barry Pollard

Michal Mocny

Date de publication : 20 avril 2026

Chrome prévoit de lancer l'API Soft Navigations que nous testons depuis quelque temps dans le courant de l'année. En préparation, nous proposons une évaluation de l'origine supplémentaire à partir de Chrome 147 jusqu'à Chrome 149. Cet essai intègre les commentaires des essais précédents dans la forme finale attendue de l'API. Nous encourageons les propriétaires de sites Web intéressés par cette fonctionnalité à effectuer un dernier test de la forme finale attendue de l'API avant sa publication.

Que sont les navigations douces ?

Une "navigation logicielle" se produit lorsque JavaScript intercepte une navigation (par exemple, un clic sur un lien) et met à jour le contenu de la page existante au lieu de charger une nouvelle page, tandis que l'URL est toujours mise à jour dans la barre d'adresse. Pour les utilisateurs, ces navigations sont identiques aux navigations classiques, mais du point de vue du navigateur, la page reste la page d'origine.

Nécessité de l'API Soft Navigation

L'API Soft Navigations est une API proposée pour la détection des navigations douces utilisées par les sites d'applications monopages (SPA). Comme aucune navigation de page réelle n'a lieu pour une navigation logicielle, JavaScript doit gérer manuellement certaines actions qui se produiraient normalement pour une navigation. Certaines actions, comme la gestion de l'historique de navigation, sont possibles avec les API actuelles. Toutefois, d'autres actions, comme la mesure des Core Web Vitals, ne sont pas possibles pour ces navigations.

L'API Soft Navigation permet d'observer les navigations douces. Alors que le code JavaScript qui lance la navigation logicielle (généralement un framework JavaScript) sait quand une navigation se produit, les autres codes JavaScript utilisés par le site (par exemple, les scripts d'analyse) et le navigateur lui-même ne le savent pas.

Core Web Vitals et les SPA

L'un des principaux objectifs de l'API Soft Navigation est de permettre la mesure des métriques Core Web Vitals pour les SPA. Les Core Web Vitals sont mesurées à la fois par le navigateur (pour apparaître dans des outils tels que le rapport d'expérience utilisateur Chrome) et par les propriétaires de sites à l'aide de solutions de surveillance des utilisateurs réels (RUM, Real User Monitoring).

Les frameworks JavaScript peuvent mesurer certains aspects des Core Web Vitals pour les SPA. En particulier, l'interaction to next paint (INP) et le Cumulative Layout Shift (CLS) sont basés sur des primitives (respectivement l'API Event Timing et l'API Layout Instability) qui peuvent être mesurées sur n'importe quelle période pour calculer ces métriques. Toutefois, d'autres métriques, comme Largest Contentful Paint (LCP), ne sont émises que par le navigateur, en fonction des navigations sur les pages et sont finalisées lors de l'interaction.

Comment l'API permet de mesurer les Core Web Vitals pour les SPA

L'API Soft Navigation introduit deux nouvelles entrées de performances :

• SoftNavigationEntry émise lorsque toutes les exigences de navigation logicielle sont remplies. Cela inclut un interactionId pour l'interaction qui a provoqué la navigation logicielle, un navigationId unique et un name défini sur la nouvelle URL, ainsi que divers timings de peinture qui peuvent être utilisés pour mesurer le premier contenu affiché de la navigation logicielle.
• Une entrée InteractionContentfulPaint qui permet de mesurer plusieurs peintures de contenu de taille croissante après les interactions pour mesurer le LCP pour les navigations douces.

Ces nouvelles entrées peuvent être observées à l'aide d'un PerformanceObserver en utilisant respectivement les types soft-navigation et interaction-contentful-paint.

L'API développe également chacune des entrées de performances largest-contentful-paint, interaction-contentful-paint, event-timing et layout-shift (et d'autres) pour inclure un identifiant, navigationId, qui représente la navigation à laquelle l'entrée se rapporte. Étant donné que les PerformanceObservers n'observent les entrées de performances que lorsque la page est inactive, un certain temps peut s'écouler entre l'événement qui a créé l'entrée de performances et votre observation de celle-ci. Cela est particulièrement vrai lorsque la page est très chargée, par exemple lors des navigations douces. Cette valeur navigationId permet d'attribuer les entrées à la bonne navigation.

Certaines entrées interaction-contentful-paint peuvent se produire avant la navigation et d'autres après. Au lieu d'avoir à suivre tous les affichages pouvant entraîner une navigation douce, l'entrée soft-navigation inclut une entrée largestInteractionContentfulPaint qui correspond au plus grand affichage vu jusqu'à présent.

Ensemble, ils permettent de mesurer les métriques Core Web Vitals pour :

• LCP : en utilisant largest-contentful-paint pour le chargement initial de la page et les nouvelles entrées interaction-contentful-paint et soft-navigation pour les navigations douces.
• CLS : utilisation des entrées layout-shift et découpage en fonction des entrées soft-navigation pour les navigations douces.
• INP : en utilisant les entrées event et en les segmentant en fonction des entrées soft-navigation pour les navigations douces.
• FCP : utilisation de first-contentful-paint pour le chargement initial de la page et des détails sur le timing de peinture dans les nouvelles entrées soft-navigation pour les navigations douces.

Pour en savoir plus, consultez la documentation sur les navigations douces.

Comment les navigations douces sont-elles déclenchées ?

L'API Soft Navigation déclenche une navigation logicielle lorsque les conditions suivantes sont remplies :

• Une interaction utilisateur se produit.
• … ce qui entraîne un affichage visible du contenu pour l'utilisateur.
• … et une mise à jour de l'URL a lieu.

L'API adopte cette approche plutôt que de laisser un framework JavaScript "émettre" une navigation logicielle ou de s'appuyer sur l'API Navigation pour deux raisons :

1. Tout d'abord, cela inclut tous les sites SPA existants, sans qu'aucune modification ne soit requise pour ces sites.
2. Deuxièmement, il permet de comprendre de manière cohérente ce qui constitue une navigation logicielle, quelle que soit la manière dont un framework ou un développeur gère les navigations.

Les frameworks ou les développeurs peuvent mettre à jour l'URL d'une navigation logicielle, même sans interaction de l'utilisateur ni mise à jour du DOM que les utilisateurs considéreraient comme une navigation. Ils peuvent également mettre à jour l'URL à différents moments : au début de l'interaction, uniquement à la fin lorsqu'elle est terminée ou à n'importe quel état intermédiaire.

Au lieu de s'appuyer sur les choix du framework et du développeur, l'intégration de la détection de la navigation douce dans le navigateur établit une définition canonique qui permet de mesurer les Core Web Vitals pour les navigations douces à grande échelle et de rendre ces mesures comparables à grande échelle.

Les frameworks et les développeurs peuvent également ignorer l'API Soft Navigations et utiliser les API Event Timing et Layout Instability sous-jacentes, ainsi que la nouvelle entrée de performances InteractionContentfulPaint, pour mesurer d'autres métriques de performances de leur choix. Toutefois, nous vous recommandons d'utiliser l'API pour mesurer les Core Web Vitals afin d'obtenir des mesures cohérentes sur les sites et dans les outils.

Besoin d'aide pour tester l'API Soft Navigation

Nous avons besoin de votre aide pour tester l'API Soft Navigations et déterminer si elle répond correctement à vos attentes lorsqu'une navigation logicielle se produit. L'API ne signale-t-elle pas les navigations douces alors que vous estimez qu'elles ont eu lieu ? À l'inverse, l'API signale-t-elle trop de navigations que vous ne considérez pas comme telles ?

Nouveautés depuis le dernier test d'origine

La principale modification apportée à cette dernière itération consiste à dissocier InteractionContentfulPaint des navigations douces pour permettre d'autres cas d'utilisation pour cette entrée de performances, ainsi que l'attribut largestInteractionContentfulPaint supplémentaire à SoftNavigationEntry.

Du point de vue d'un site Web, l'API inclut désormais également replaceState en tant que navigation douce, car nous avons tenu compte de vos commentaires indiquant qu'il est important de considérer cela comme une navigation dans de nombreuses circonstances. Nous aimerions connaître tous les autres cas où l'API ne reconnaît pas une navigation douce.

Nous avons également apporté d'innombrables autres améliorations à l'implémentation. Pour ceux qui souhaitent savoir exactement ce qui a changé dans la dernière itération, un historique détaillé de toutes les modifications est disponible dans le journal des modifications des navigations douces.

Nous souhaitons que l'API soit aussi utile que possible et nous sommes ouverts à d'autres modifications pour y parvenir. Il est beaucoup plus facile d'implémenter des modifications dans l'API avant son lancement et avant que les sites ne commencent à dépendre d'une implémentation. Nous invitons donc les développeurs de SPA et les personnes intéressées par la mesure des performances Web pour ces sites à tester cette API et à nous faire part de leurs commentaires.

Comment tester

L'API peut être testée localement avec des indicateurs Chrome ou des options de ligne de commande. Vous pouvez également le tester sur le terrain avec l'origin trial (en savoir plus sur les origin trials).

Pour en savoir plus sur l'API, en particulier sur la façon de mesurer les signaux Web essentiels, consultez notre documentation ou le dépôt GitHub.

De plus, une version expérimentale de la bibliothèque web-vitals pour la navigation logicielle est disponible sur GitHub et npm.

Pour un test plus simple, le panneau Performances des outils pour les développeurs Chrome affiche les navigations douces dans les traces de performances à partir de Chrome 145, même sans activer la fonctionnalité :

Commentaires

Les commentaires sur l'API doivent être signalés en tant que problèmes sur GitHub, et les bugs sur l'implémentation Chromium doivent être signalés dans l'outil de suivi des problèmes de Chrome. Si vous n'êtes pas sûr de la catégorie dans laquelle classer vos commentaires, ne vous inquiétez pas. Nous préférons recevoir vos commentaires dans l'un ou l'autre de ces endroits. Nous trierons les problèmes dans les deux et les redirigerons vers le bon endroit.