La Soft Navigations API, présentée à Google I/O 2026, permet enfin de mesurer correctement les Core Web Vitals des applications monopage (SPA) en reconnaissant les transitions internes comme de vraies navigations. Jusqu'ici, ces transitions échappaient à la mesure standard, faussant les indicateurs de performance des SPA.
Le problème était bien connu des équipes techniques : une application React, Vue ou autre charge une fois la page initiale, puis change de vue sans recharger le navigateur. Pour les outils de mesure classiques, il ne se passe alors plus rien, alors que l'utilisateur, lui, perçoit bien un changement de page parfois lent. Les Core Web Vitals d'une SPA étaient donc partiels et trompeurs.
Cet article rappelle ce que sont les Core Web Vitals, explique précisément pourquoi les SPA les mesuraient mal, détaille ce qu'apporte la Soft Navigations API, son impact SEO, et donne des conseils concrets. Chez Genee, agence de développement sur mesure, la performance réelle perçue par l'utilisateur est au cœur de notre méthode.
Rappel : ce que sont les Core Web Vitals
Les Core Web Vitals sont trois indicateurs de Google qui mesurent l'expérience réelle d'une page : la vitesse de chargement (LCP), la réactivité aux interactions (INP) et la stabilité visuelle (CLS). Ils influencent à la fois le confort utilisateur et le référencement.
Le détail des trois métriques :
- LCP (Largest Contentful Paint) : le temps que met le plus grand élément visible à s'afficher. Un bon LCP est inférieur à 2,5 secondes.
- INP (Interaction to Next Paint) : la réactivité globale aux interactions de l'utilisateur (clics, saisies). Un bon INP est inférieur à 200 millisecondes. L'INP a remplacé le FID en 2024.
- CLS (Cumulative Layout Shift) : la stabilité visuelle, c'est-à-dire l'absence de décalages intempestifs de la mise en page. Un bon CLS est inférieur à 0,1.
Google utilise ces indicateurs comme signal de classement et les surveille via les données de terrain (Chrome User Experience Report). Un site lent ou instable est pénalisé deux fois : par les utilisateurs qui partent et par un référencement dégradé. C'est pourquoi leur mesure exacte est cruciale.
Pourquoi les SPA mesuraient mal leurs CWV
Une SPA mesurait mal ses Core Web Vitals parce que les outils ne reconnaissaient qu'un seul chargement, celui de la page initiale, et ignoraient les transitions internes qui constituent pourtant l'essentiel de la navigation. Le résultat : des métriques flatteuses mais incomplètes.
Le mécanisme du problème :
- Une application monopage charge une fois le document HTML, puis met à jour le contenu via JavaScript sans recharger le navigateur.
- Les Core Web Vitals étaient historiquement attachés à ce chargement initial unique.
- Quand l'utilisateur passe d'une vue à une autre dans la SPA, aucun nouveau cycle de mesure ne démarrait.
Conséquence concrète : si votre page d'accueil charge vite mais que passer à la fiche produit prend trois secondes avec des décalages visuels, cette mauvaise expérience n'apparaissait pas dans les Core Web Vitals. La métrique disait « tout va bien » alors que l'utilisateur subissait des transitions lentes. C'était une des « réalités contradictoires » classiques : un indicateur vert pour une expérience réelle dégradée.
Cette cécité posait deux problèmes : un angle mort dans le diagnostic de performance, et une difficulté à optimiser ce qu'on ne mesure pas. Beaucoup d'équipes optimisaient à l'aveugle les transitions de leur SPA.
Ce qu'apporte la Soft Navigations API
La Soft Navigations API permet au navigateur de détecter les transitions internes d'une SPA comme de véritables navigations, et donc de mesurer les Core Web Vitals pour chacune d'elles, pas seulement au premier chargement. C'est la fin de l'angle mort.
Une soft navigation est une transition au sein d'une SPA qui présente les caractéristiques d'une vraie navigation : déclenchée par une interaction de l'utilisateur, modification de l'URL, et changement substantiel du contenu affiché. L'API reconnaît ces transitions et réinitialise le cycle de mesure.
Les apports concrets :
- Des CWV par vue : LCP, INP et CLS sont désormais mesurables pour chaque transition interne, pas uniquement pour le chargement initial.
- Des données de terrain fidèles : les outils de mesure réelle peuvent capter l'expérience complète de la navigation dans la SPA.
- Un diagnostic exploitable : on identifie enfin quelles transitions sont lentes et où optimiser.
L'annonce s'inscrit dans un ensemble de nouveautés présentées à Google I/O 2026 visant à mieux outiller les applications web modernes, aux côtés des Declarative Partial Updates et des streaming APIs. Pour un panorama des leviers de performance, voir nos 10 optimisations de performance web.
Comment fonctionne une soft navigation
Le navigateur identifie une soft navigation lorsqu'une interaction utilisateur déclenche un changement d'URL accompagné d'une modification significative du contenu de la page, puis il attache un nouveau cycle de mesure des Core Web Vitals à cet événement. Trois conditions sont donc combinées.
Les critères de détection :
- Une interaction utilisateur : un clic ou une action qui initie la transition, par opposition à une mise à jour automatique en arrière-plan.
- Un changement d'URL : la SPA modifie l'adresse via l'API History, signalant une nouvelle vue.
- Une modification substantielle du contenu : le DOM change de manière significative, indiquant un vrai changement de page et non un simple rafraîchissement mineur.
Quand ces conditions sont réunies, le navigateur traite la transition comme une nouvelle navigation et recommence à mesurer LCP, INP et CLS dans ce nouveau contexte. Les outils de mesure et les bibliothèques de suivi de performance peuvent alors remonter ces données.
Pour les développeurs, cela implique surtout de respecter ces conventions : utiliser correctement l'API History pour les changements de vue, déclencher les transitions sur de vraies interactions, et structurer le contenu pour que le changement soit détectable. Une SPA bien construite bénéficie naturellement de l'API ; une SPA qui détourne les mécanismes de navigation risque de ne pas être correctement mesurée.
Impact sur le SEO et la performance perçue
La Soft Navigations API rend la mesure des Core Web Vitals d'une SPA conforme à l'expérience réelle, ce qui peut révéler des problèmes de performance jusqu'ici invisibles et donc influençant indirectement le SEO et la satisfaction utilisateur. La transparence joue dans les deux sens.
Les conséquences à anticiper :
- Fin de l'illusion : des SPA qui affichaient de bons CWV grâce à un chargement initial rapide peuvent voir apparaître de mauvais scores sur leurs transitions internes. Ce n'est pas une régression, c'est la vérité qui émerge.
- Diagnostic actionnable : pouvoir mesurer chaque transition permet d'optimiser précisément, plutôt qu'à l'aveugle.
- Alignement SEO et UX : optimiser les CWV réels améliore à la fois l'expérience perçue et les signaux que Google exploite.
L'enjeu n'est pas de craindre la nouvelle mesure, mais de l'embrasser. Une équipe qui découvre que sa transition vers le tunnel de commande est lente détient enfin l'information pour la corriger. Le pire scénario est de continuer à se rassurer avec des indicateurs partiels pendant que des utilisateurs abandonnent à cause de transitions lentes.
Cette logique rejoint une conviction de fond : un indicateur vert ne vaut rien s'il ne reflète pas l'expérience réelle. La performance perçue par l'utilisateur reste le juge ultime.
Conseils concrets pour les équipes
Pour tirer parti de la Soft Navigations API, auditez les transitions de votre SPA, optimisez celles qui sont lentes, et mettez en place un suivi des Core Web Vitals par vue plutôt qu'au seul chargement initial. Voici une feuille de route directement applicable.
Les actions prioritaires :
- Cartographier les transitions clés : lister les changements de vue les plus fréquents et les plus importants commercialement (accueil vers produit, produit vers panier, panier vers paiement).
- Mesurer chaque transition : instrumenter le suivi des CWV pour les soft navigations, pas seulement le chargement initial, afin d'identifier les points lents.
- Optimiser le LCP des vues : précharger les ressources critiques de la vue cible, éviter de tout recharger inutilement à chaque transition.
- Maîtriser le CLS : réserver l'espace des éléments qui arrivent en différé pour éviter les décalages pendant la transition.
- Surveiller l'INP : éviter les traitements JavaScript lourds qui bloquent l'interface pendant les transitions.
- Respecter les conventions de navigation : utiliser correctement l'API History pour que le navigateur détecte bien les soft navigations.
Le bon réflexe est d'intégrer la mesure des transitions dès la conception, et non de la découvrir après coup. Une SPA pensée pour la performance dès le départ évite la dette technique coûteuse à corriger plus tard.
L'approche Genee
Genee conçoit des applications web et SPA en plaçant la performance réelle perçue par l'utilisateur au centre, avec une mesure des Core Web Vitals sur l'ensemble des parcours, transitions internes comprises. Nous refusons de nous satisfaire d'indicateurs partiels.
Concrètement, nos interventions incluent :
- L'audit de performance complet de votre SPA, en mesurant les transitions internes et pas uniquement le chargement initial, pour révéler les angles morts.
- L'optimisation ciblée des transitions lentes : préchargement, découpage du code, gestion du CLS et de l'INP sur les parcours critiques.
- La mise en place d'un suivi durable des Core Web Vitals par vue, intégrant les apports de la Soft Navigations API.
- La conception performante par défaut sur nos projets de développement SaaS, où chaque transition est pensée pour rester fluide.
Notre conviction est simple : une mesure honnête est la condition d'une vraie performance. Si vous voulez savoir comment se comporte réellement votre application au fil des parcours et non au seul premier écran, parlons-en. Nous combinons expertise technique et exigence sur le rendu réel.
FAQ — Core Web Vitals d'une SPA : la Soft Navigations API enfin disponible
La Soft Navigations API est-elle disponible dans tous les navigateurs ?
La Soft Navigations API a été présentée à Google I/O 2026 et son déploiement commence dans Chrome. Comme pour toute API web récente, sa disponibilité dans d'autres navigateurs dépend de leur calendrier d'implémentation. Concevoir sa SPA selon les bonnes pratiques de navigation reste le meilleur moyen d'en bénéficier dès qu'elle est supportée.
Dois-je modifier ma SPA pour qu'elle soit mesurée correctement ?
Si votre SPA utilise correctement l'API History pour ses changements de vue et déclenche ses transitions sur de vraies interactions, elle est en bonne position pour être détectée comme soft navigation. Les applications qui détournent les mécanismes de navigation peuvent en revanche nécessiter des ajustements pour être correctement mesurées.
Mes Core Web Vitals risquent-ils de se dégrader avec cette API ?
Vos scores réels ne se dégradent pas, ils deviennent simplement plus fidèles à l'expérience vécue. Si vos transitions internes étaient lentes, l'API les révèlera, là où elles étaient auparavant invisibles. C'est une opportunité d'optimisation, pas une pénalité : on ne peut corriger que ce que l'on mesure.
Quelle différence entre une hard navigation et une soft navigation ?
Une hard navigation est un rechargement complet de la page par le navigateur, comme lorsqu'on clique sur un lien classique vers une nouvelle URL. Une soft navigation est une transition interne au sein d'une SPA, sans rechargement du document, déclenchée par une interaction et accompagnée d'un changement d'URL et de contenu.
Faut-il abandonner les SPA au profit du rendu serveur ?
Pas nécessairement. Les SPA restent pertinentes pour des applications interactives, et la Soft Navigations API comble justement leur principal point faible en matière de mesure. Le choix dépend du besoin : certaines pages gagnent au rendu serveur pour le SEO et le premier affichage, d'autres restent mieux servies par une SPA bien optimisée.