Publié le : 31 juillet 2025
Chrome lance une nouvelle phase d'évaluation à partir de Chrome 139 pour l'API Soft Navigations que nous avons déjà testée. Cet essai d'origine permet aux sites de tester l'API sur leur site avec de vrais utilisateurs afin de la tester sur le terrain et de fournir des commentaires à l'équipe Chrome.
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, plutôt que de charger une nouvelle page. L'URL est ensuite mise à jour dans la barre d'adresse (avec un état d'historique pour permettre les navigations logicielles vers l'avant et vers l'arrière). Pour l'utilisateur, ces navigations ressemblent aux navigations classiques, mais pour le navigateur, la page reste la page d'origine.
Pourquoi l'API Soft Navigation est-elle nécessaire ?
L'API Soft Navigations est une API proposée pour permettre la détection heuristique des "soft navigations" utilisées par les sites d'applications monopages (SPA). Comme aucune navigation de page réelle ne se produit pour une navigation logicielle, cela signifie que certaines actions qui se produiraient normalement pour une navigation doivent être gérées manuellement par JavaScript. 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 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 les outils tels que le rapport d'expérience utilisateur Chrome) et par les bibliothèques JavaScript de surveillance des utilisateurs réels (RUM, Real User Monitoring).
Les frameworks JavaScript peuvent mesurer certains aspects des Core Web Vitals. 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 les métriques INP et CLS. 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 Soft Navigation permet de mesurer les métriques Core Web Vitals pour les SPA
La première itération de l'API Soft Navigation a associé l'heuristique de navigation logicielle à une réinitialisation du LCP. Une fois réinitialisé, le LCP peut être réémis pour les navigations douces pour une nouvelle peinture de contenu, ce qui permet de mesurer cette métrique pour les navigations douces.
Cette dernière itération adopte une approche différente et dissocie ces concepts dans l'API Soft Navigation et une nouvelle entrée de performances "Interaction to Contentful Paint". L'entrée interaction-contentful-paint mesure le "contentful paint" après les interactions. Pour l'instant, cet événement n'est émis que pour les navigations douces, mais il ouvre d'autres cas d'utilisation potentiels au-delà du LCP s'il est activé pour toutes les interactions.
L'API a également étendu chacune des entrées de performances largest-contentful-paint, interaction-contentful-paint, event-timing et layout-shift pour inclure un identifiant de la navigation à laquelle l'entrée se rapporte. Les entrées de performances sont émises après l'événement qu'elles mesurent, généralement pendant les périodes d'inactivité. Cela signifie que l'URL aura souvent changé au moment où l'entrée de performance est émise. L'inclusion de la navigation avec l'entrée permet de mesurer beaucoup plus facilement les métriques Core Web Vitals pour l'URL donnée, sans avoir à faire correspondre les heures d'entrée des performances avec les heures d'entrée de la navigation logicielle.
Pourquoi une heuristique ?
L'API Soft Navigation considère qu'une navigation logicielle se produit lorsque les conditions suivantes sont remplies :
- Une interaction basée sur l'utilisateur se produit (les mises à jour d'URL sans interaction de l'utilisateur ne sont pas comptabilisées).
- … ce qui entraîne une modification du DOM et un rendu.
- … et une URL est modifiée
- Mise à jour de l'URL, y compris une modification de l'historique.
L'API adopte cette approche heuristique plutôt que de permettre à un framework JavaScript d'"émettre" une navigation douce ou d'être basé sur l'API Navigation. Cela permet de comprendre de manière cohérente ce qui constitue une navigation douce, quel que soit le framework ou la façon dont un développeur l'utilise.
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 nous considérons comme une navigation visible par l'utilisateur. Ils peuvent également mettre à jour l'URL à différents moments : au début de l'interaction, à la fin lorsqu'elle est terminée ou à n'importe quel moment entre les deux.
Plutôt que de s'appuyer sur des choix de framework, l'intégration de la détection de la navigation logicielle dans le navigateur établit des "heuristiques" canoniques (avec vos commentaires issus de cet Origin Trial). Cela nous permettra de mesurer les métriques Core Web Vitals pour les navigations logicielles à grande échelle et de rendre ces mesures comparables à grande échelle.
Les frameworks et les développeurs peuvent également ignorer les heuristiques de l'API Soft Navigations et utiliser les API Event Timing, Layout Instability et Interaction to Contentful Paint sous-jacentes pour mesurer d'autres métriques de performances comme ils le souhaitent. Toutefois, nous recommandons d'utiliser les métriques Core Web Vitals avec l'heuristique pour permettre la mesure sur les sites.
Besoin d'aide pour tester l'API Soft Navigation
Nous avons besoin d'aide pour tester l'API Soft Navigations et vérifier si l'heuristique correspond correctement à vos attentes concernant le moment où une navigation logicielle s'est produite. Existe-t-il des cas où l'API ne signale pas de navigation douce alors que vous estimez qu'il y en a eu ? À l'inverse, l'API signale-t-elle des navigations répétées que vous ne considérez pas comme des navigations douces ?
Par exemple, nous avons constaté que des problèmes se produisaient lorsqu'une URL était mise à jour avec replaceState au lieu d'ajouter un historique, ou lorsqu'une navigation non initiée par l'utilisateur se produisait (par exemple, une déconnexion en cas de délai d'inactivité). Dans les deux cas, l'explication est que les heuristiques ne correspondent pas. L'équipe Chrome est d'accord pour ne pas les inclure, mais nous aimerions savoir si les développeurs Web sont d'accord. Nous souhaitons en particulier en savoir plus sur les cas où les heuristiques semblent être respectées, mais où l'API ne reconnaît toujours pas la navigation douce.
De plus, nous souhaitons savoir si cette API et la nouvelle primitive Interaction to Contentful Paint répondent au principal cas d'utilisation, qui consiste à permettre la mesure des métriques Core Web Vitals pour les SPA.
Nous souhaitons que l'API soit aussi utile que possible. Il est beaucoup plus facile d'y parvenir 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 leur expérience.
Comment tester
L'API peut être testée localement avec des indicateurs Chrome ou des options de ligne de commande. Il peut également être testé sur le terrain avec la phase d'évaluation.
Pour en savoir plus sur les détails techniques de l'API, et en particulier sur la façon de mesurer les signaux vitaux Web, consultez notre documentation ou le dépôt GitHub. Une version expérimentale de la bibliothèque web-vitals pour la navigation douce est également disponible.
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.