Publié le 31 juillet 2025
Chrome lance une nouvelle phase d'évaluation à partir de Chrome 139 pour l'API Soft Navigations que nous avons testée précédemment. Cette phase d'évaluation 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 logicielles ?
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 en arrière et en avant). Pour l'utilisateur, elles 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 "navigations logicielles" 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, telles que la mesure des Core Web Vitals, ne sont pas possibles pour ces navigations.
L'API Soft Navigation permet d'observer les navigations logicielles. Bien que le code JavaScript qui lance la navigation logicielle (généralement un framework JavaScript) sache quand une navigation se produit, les autres codes JavaScript et le navigateur lui-même ne le sauront pas.
Core Web Vitals et SPA
L'un des principaux moteurs de l'API Soft Navigation est de permettre la mesure des Core Web Vitals pour les SPA. Les Core Web Vitals sont mesurées à la fois par le navigateur (pour apparaître dans l'outil tel que le rapport d'expérience utilisateur Chrome) et par les bibliothèques JavaScript Real User Monitoring (RUM).
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 (l'API Event Timing et l'API Layout Instability respectivement) qui peuvent être mesurées sur n'importe quelle période pour calculer les métriques INP et CLS. Toutefois, comme le navigateur signale et finalise Largest Contentful Paint (LCP) en fonction des navigations et des interactions de la page, les frameworks JavaScript n'ont de visibilité que sur les performances de chargement initiales des SPA.
Comment l'API Soft Navigation permet-elle de mesurer les 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 logicielles pour une nouvelle peinture de contenu, ce qui permet de mesurer cette métrique pour les navigations logicielles.
Cette dernière itération adopte une approche différente et découple 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 la "peinture de contenu" après les interactions. Pour le moment, elle n'est émise que pour les navigations logicielles, mais cela 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 pour la navigation de l'entrée. 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 performances est émise. L'inclusion de la navigation dans l'entrée facilite grandement la mesure des Core Web Vitals pour l'URL donnée, sans avoir à faire correspondre les heures d'entrée de performances aux heures d'entrée de navigation logicielle.
Pourquoi une heuristique ?
L'API Soft Navigation considère une navigation logicielle 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 prises en compte).
- … ce qui entraîne une modification du DOM et une peinture
- … et une mise à jour de l'URL se produit
- 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 logicielle ou d'être basé sur l'API Navigation, car cela permet de comprendre de manière cohérente ce qui constitue une navigation logicielle, quel que soit le framework ou la manière 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 pour l'utilisateur. Ils peuvent également mettre à jour l'URL à différents moments : au début de l'interaction, à la fin seulement lorsqu'elle est terminée ou à n'importe quel état intermédiaire.
Plutôt que de nous appuyer sur les choix de framework, l'intégration de la détection de navigation logicielle dans le navigateur établit des "heuristiques" canoniques (avec vos commentaires de cette phase d'évaluation) qui nous permettront de mesurer les 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 l'heuristique de l'API Soft Navigations et utiliser les API sous-jacentes Event Timing, Layout Instability et Interaction to Contentful Paint pour mesurer les métriques de performances supplémentaires de leur choix. Toutefois, nous recommandons d'utiliser les Core Web Vitals avec l'heuristique pour permettre la mesure sur tous les sites.
Aide nécessaire pour tester l'API Soft Navigation
Nous avons besoin d'aide pour tester l'API Soft Navigations afin de vérifier si l'heuristique correspond correctement à vos attentes concernant le moment où une navigation logicielle s'est produite. Y a-t-il des cas où l'API ne signale pas de navigations logicielles alors que vous considérez qu'elles se sont produites ? À l'inverse, l'API répète-t-elle des navigations que vous ne considérez pas comme des navigations logicielles ?
Parmi les exemples qui ont causé des problèmes, citons le cas où une URL est mise à jour avec replaceState au lieu d'ajouter un historique, ou lorsqu'une navigation qui n'est pas initiée par l'utilisateur se produit (par exemple, une déconnexion en cas de délai d'inactivité). Dans les deux cas, l'heuristique ne correspond pas, et l'équipe Chrome est d'accord pour ne pas les inclure, mais nous souhaitons savoir si les développeurs Web sont d'accord. Nous souhaitons en particulier connaître les cas où l'heuristique semble être respectée, mais où l'API ne reconnaît toujours pas la navigation logicielle.
De plus, nous voulons savoir si cette API et la nouvelle primitive Interaction to Contentful Paint répondent au cas d'utilisation principal qui consiste à permettre la mesure des Core Web Vitals pour les SPA.
Nous souhaitons que l'API soit aussi utile que possible, ce qui est beaucoup plus facile à faire avant son lancement et que les sites commencent à dépendre d'une implémentation. Par conséquent, nous demandons aux développeurs de SPA et à ceux qui souhaitent mesurer les performances Web de ces sites de tester cette API et de nous indiquer comment elle fonctionne pour vous.
Comment tester
L'API peut être testée localement avec des flags Chrome ou des options de ligne de commande. De plus, elle peut être testée 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 mesure des Core Web Vitals, consultez notre documentation ou le dépôt GitHub. De plus, une version expérimentale de navigation logicielle de la bibliothèque web-vitals est disponible.
Commentaires
Nous recherchons activement des commentaires sur cette expérience aux endroits suivants :
- Les commentaires sur l'API doivent être signalés comme des problèmes sur GitHub.
- Les bugs de l'implémentation Chromium doivent être signalés dans l'outil de suivi des problèmes de Chrome, s'il ne s'agit pas encore d'un problème connu.
- Les commentaires généraux sur les Web Vitals peuvent être partagés à l'adresse web-vitals-feedback@googlegroups.com.
En cas de doute, ne vous inquiétez pas trop. Nous préférons recevoir les commentaires à l'un ou l'autre endroit. Nous allons trier les problèmes aux deux endroits et les rediriger vers l'emplacement approprié.