Core Web Vitals : CrUX mesure enfin les navigations « soft » des applications monopages

Chrome a publié le 13 octobre 2026 trois versions expérimentales des Core Web Vitals qui tiennent compte des navigations « soft », ces changements de page sans rechargement propres aux applications monopages. Elles sont disponibles dès la publication CrUX d’octobre, à côté des scores stables, qui ne changent pas.

L’essentiel

• Depuis la publication CrUX d’octobre 2026, trois champs expérimentaux mesurent LCP, INP et CLS en incluant les navigations soft.
• Les données sont accessibles dans BigQuery, l’API CrUX, l’API CrUX History et CrUX Vis.
• Les scores Core Web Vitals stables restent inchangés.
• Chrome vise une sortie de l’expérimental en mai 2027, après quoi la Search Console passera aux nouvelles données.

Navigation soft : l’angle mort de CrUX jusqu’ici

Une application monopage (SPA, pour single-page application) ne charge un document HTML qu’une fois. Ensuite, chaque clic remplace le contenu et l’URL en JavaScript, sans rechargement complet. Jusqu’à présent, CrUX ignorait ces transitions : toutes les interactions et tous les décalages de mise en page de la session étaient rattachés à la page d’arrivée. Dix vues successives dans une même session se retrouvaient donc créditées à une seule URL.

Chrome retient trois conditions pour parler de navigation soft. Elle part d’une action de l’internaute, l’URL visible change, et l’interaction produit un affichage à l’écran. La documentation Chrome sur les soft navigations admet que cette définition peut produire des faux positifs, et laisser passer des navigations que l’internaute perçoit comme telles. La détection repose sur l’API Soft Navigations, activée par défaut depuis Chrome 151, sorti le 28 juillet 2026 selon Search Engine Journal.

Trois champs expérimentaux dans BigQuery, l’API CrUX et CrUX Vis

L’annonce est signée Annie Sullivan, de l’équipe Chrome, dans un billet publié sur web.dev. Trois champs font leur apparition : experimental_largest_contentful_paint_with_softnavs, experimental_interaction_to_next_paint_with_softnavs et experimental_cumulative_layout_shift_with_softnavs. Ils reprennent les mesures des champs stables, à une différence près : chaque changement de vue qui modifie le contenu et l’URL compte comme une navigation à part entière.

Le LCP est désormais mesuré sur les navigations classiques comme sur les navigations soft. L’INP est calculé par page vue, et non plus sur l’ensemble de la session. Le CLS, lui, est évalué vue par vue et URL par URL au lieu de s’accumuler. Dans l’API CrUX, les métriques sont attribuées à l’URL vers laquelle l’internaute a navigué, et non à la page d’arrivée, sous réserve des critères d’éligibilité habituels. CrUX Vis a été mis à jour pour afficher ces nouvelles métriques sur n’importe quelle URL ou origine. La publication de novembre doit ajouter des versions soft navigation du FCP et des types de navigation.

70 % des origines ne verront presque rien bouger

D’après Chrome, environ 70 % des origines présentes dans CrUX ont peu ou pas de trafic en navigation soft (moins de 5 % des pages vues). Seules 7 % des origines sur Android et 10,6 % sur ordinateur passent par des navigations soft pour plus de la moitié de leurs pages vues. La proportion grimpe sur les gros sites : parmi les 1 000 premiers, 35 % sur Android et 42 % sur ordinateur sont dans ce cas.

Pour ces sites, l’écart est net. Sur Android, la part d’origines avec un « bon » LCP passe de 26 % à 87 % chez celles qui font 75 à 100 % de navigations soft. Le taux de réussite INP double à peu près sur Android pour les sites majoritairement en navigation soft, sans que les SPA rattrapent les sites multipages. Côté CLS, elles font jeu égal avec eux sur ordinateur et restent un peu en retrait sur Android. Search Engine Journal cite par ailleurs les notes de version du jeu de données de septembre : la part d’origines qui valident les Core Web Vitals y passe de 55,9 % sans les navigations soft à 59,5 % avec.

Annie Sullivan met en garde contre une lecture trop rapide. Ce gain « ne vient pas de ce que les SPA seraient globalement plus rapides que les sites multipages » (traduction) : les clics qui suivent le premier chargement sont plus rapides sur tout type de site, puisque le code et les ressources sont déjà téléchargés. Un travail JavaScript lourd sur le thread principal pendant les changements de route « peut toujours causer des problèmes d’INP » (traduction). Chrome prévient aussi qu’il faut s’attendre à des variations d’un mois sur l’autre, le temps que la mesure s’affine.

Search Console : pas de bascule avant mai 2027

Chrome vise une sortie du statut expérimental en mai 2027, sous réserve des retours reçus. La Search Console ne passera aux nouvelles données qu’ensuite. Pour rappel, le cycle de vie des métriques Web Vitals prévoit une phase « pending » (en attente) d’au moins six mois avant le statut stable ; Search Engine Journal note que Google n’a pas précisé quelle étape suivrait ici. Le billet ne dit rien du classement ni de la Page Experience. Les retours passent par le groupe web-vitals-feedback ou par le dépôt GitHub de la spécification soft navigations du WICG.

React, Vue, Next.js : comment tester dès maintenant

Google ne cite aucun framework. En pratique, sont concernés les sites dont le routage se fait côté client : React Router, Vue Router, ou les liens internes de Next.js et de Nuxt après le premier rendu serveur. Un site qui recharge la page à chaque clic, comme la plupart des sites WordPress, ne verra aucune différence. Pour les autres, trois vérifications sont possibles sans attendre :

1. Dans CrUX Vis, afficher les métriques avec navigations soft sur l’origine et sur les principaux modèles d’URL, puis comparer avec les scores stables.
2. Dans BigQuery, interroger les champs experimental_*_with_softnavs à côté des champs stables pour suivre l’écart mois par mois.
3. Dans votre propre outil de mesure terrain (RUM), observer les entrées de type « soft-navigation » via PerformanceObserver, ou passer l’option reportSoftNavs à la bibliothèque web-vitals, dont la documentation Chrome situe la prise en charge à partir de la version 6.

Ce que j’en retiens

Cette mesure corrige un biais ancien. Avec un LCP calculé sur le seul chargement initial, une SPA était jugée sur sa page la plus lente. Le saut de 26 % à 87 % de bons LCP laisse penser que le problème tenait en bonne partie à la façon de mesurer. Je ne conseillerais donc à personne de migrer une application React vers du multipage pour des raisons de Core Web Vitals sans avoir d’abord regardé ces données expérimentales.

L’INP, en revanche, mérite qu’on s’y attarde. Sur un site Next.js ou Vue, chaque transition de route sera désormais évaluée, avec ses points faibles habituels : hydratation tardive, gros bundles chargés au clic, appels d’API bloquants. C’est là qu’il faut chercher, dans CrUX Vis et dans le RUM. Il reste au moins sept mois avant que la Search Console change de source.