Core Web Vitals d’une SPA : mesurer chaque navigation
Chrome 151 mesure les navigations douces des SPA. Construisez un RUM par route, comparez chargements complets et transitions, puis priorisez les lenteurs.
Pour mesurer les Core Web Vitals d’une SPA, il faut désormais séparer le chargement complet de la première URL et les navigations internes qui remplacent le contenu sans recharger le document. Chrome 151 expose une navigation douce lorsque trois événements se rencontrent : une interaction, un changement d’URL visible et un nouveau rendu à l’écran. Cette frontière permet d’attribuer LCP, INP et CLS à la route réellement vécue.
La nouveauté ne rend pourtant ni CrUX, ni Search Console, ni tous les navigateurs immédiatement comparables. Le protocole utile consiste donc à conserver deux séries : la mesure historique des chargements complets et une mesure RUM par navigation douce, segmentée par support. La bonne question n’est pas « le score de la SPA est-il bon ? », mais quelle route, dans quel contexte, retarde une action importante ?
Ce que Chrome 151 change pour les SPA
Une application monopage, ou single-page application (SPA), charge un document initial puis modifie son contenu avec JavaScript. Le routeur peut changer l’URL, récupérer des données et afficher un nouvel écran sans navigation complète du navigateur. Pour la personne, il s’agit bien d’une nouvelle page. Pour les outils de mesure historiques, toute la session pouvait rester rattachée au document initial.
Chrome 151, dont la date de version stable est le 28 juillet 2026 et dont le déploiement stable desktop a été annoncé le 4 août, ajoute deux types d’entrées à la chronologie de performance :
soft-navigation, qui identifie la nouvelle URL, l’interaction d’origine et un identifiant de navigation ;interaction-contentful-paint, qui observe les nouveaux rendus de contenu produits par l’interaction et permet de calculer un LCP propre à la transition.
La documentation Chrome 151 décrit ce nouveau point d’observation. La méthode détaillée des navigations douces précise toutefois qu’une détection peut manquer une transition perçue comme une page ou, au contraire, classer comme navigation un changement d’état que l’équipe ne traiterait pas ainsi. L’API fournit une frontière commune ; elle ne connaît pas le sens métier de chaque route.
Une navigation douce ne correspond donc pas à tout changement d’interface. Elle suppose :
- une action de l’utilisateur ;
- une URL visible qui change ;
- un contenu visible qui est rendu.
Un onglet qui filtre une liste sans modifier l’URL, une actualisation silencieuse de données ou une animation autonome ne remplissent pas nécessairement cette définition. Ils peuvent rester importants pour l’expérience, mais demandent une autre instrumentation.
Pourquoi la première page masquait une partie du parcours
Un test Lighthouse lancé sur /tableau-de-bord/ mesure un chargement reproductible de cette URL. Il ne raconte pas ce qui se passe ensuite lorsque la personne ouvre /clients/, filtre une liste, puis affiche /rapports/ dans le même document.
Cette différence crée quatre angles morts fréquents :
- le JavaScript initial paraît rapide, mais un module chargé au premier changement de route bloque l’interaction ;
- une route récupère une réponse lente et laisse un espace vide sans retour compréhensible ;
- un contenu injecté déplace les contrôles après la navigation ;
- une longue session accumule des interactions lentes ou des décalages sans montrer quelle route les a produits.
Le guide web.dev sur les SPA et les Core Web Vitals confirme que Chrome 151 permet maintenant de mesurer les transitions de route. Il précise aussi qu’en août 2026, les bibliothèques, outils RUM et DevTools commencent seulement à intégrer ces API. Surtout, Chrome n’a annoncé aucun calendrier d’intégration dans le Chrome User Experience Report (CrUX), tandis que les autres moteurs de navigateur ne les prennent pas encore en charge.
Il faut en tirer une limite nette : cette nouvelle série sert d’abord à diagnostiquer l’expérience réelle. Elle ne doit pas être présentée comme une nouvelle donnée déjà visible dans Search Console, ni comme un changement immédiat du signal de classement.
La matrice Zence : route, navigation, métrique, support, preuve
Avant d’ajouter une bibliothèque, créez une ligne par transition importante. La matrice évite de collecter des mesures impossibles à interpréter.
| Objet | Question à documenter | Donnée à conserver | Preuve qui permet d’agir |
|---|---|---|---|
| Route | quelle URL et quelle action métier sont concernées ? | URL normalisée, modèle de page, étape du parcours | la route mène à une recherche, un choix, une validation ou une reprise identifiable |
| Navigation | le document est-il rechargé ou mis à jour ? | navigate, reload, soft-navigation, retour arrière |
la même route est comparée dans des contextes réellement différents |
| Métrique | quel défaut est perçu ? | LCP, INP, CLS et, si utile, FCP | la métrique correspond à une attente, un blocage ou un déplacement observé |
| Support | le navigateur expose-t-il la nouvelle API ? | famille, version et présence de soft-navigation |
les séries Chromium 151+ restent séparées des replis et navigateurs non compatibles |
| Preuve | que s’est-il passé autour de la mesure ? | version, appareil, réseau, route précédente, statut de requête | une régression peut être reproduite puis reliée à une livraison ou à une dépendance |
| Décision | quelle action changera si la valeur se dégrade ? | seuil interne, responsable et règle d’escalade | l’équipe sait corriger, approfondir ou ne rien faire |
Cette matrice prolonge la règle d’un audit technique de site web : séparer l’observation, l’hypothèse, la correction et la validation. Une valeur élevée sur une route est une observation. « Le framework est trop lourd » reste une hypothèse tant que la trace, les ressources ou les tâches principales ne l’expliquent pas.
Comment lire LCP, INP et CLS après une navigation douce
Les noms restent les mêmes, mais leur périmètre change. Comparer une valeur de chargement complet et une valeur de navigation douce sans conserver le type de navigation peut produire une conclusion trompeuse.
LCP : le plus grand nouveau contenu rendu
Lors d’un chargement complet, le Largest Contentful Paint (LCP) peut être une grande image déjà présente dans la page. Lors d’une navigation douce, l’API considère les nouveaux rendus associés à l’interaction. Un hero conservé entre deux routes n’est pas repeint et ne devient donc pas candidat au LCP de la seconde route.
La mesure répond à une question utile : combien de temps s’écoule entre l’interaction qui lance la route et l’affichage de son nouveau contenu principal ? Elle ne cherche pas à reproduire artificiellement un chargement à froid.
INP : la réactivité repart sur la nouvelle route
L’Interaction to Next Paint (INP) observe la latence des interactions. Dans une session longue, attribuer toutes les interactions au document initial empêchait de localiser la route où la réactivité se dégrade. Le découpage par navigation remet la mesure à zéro pour la nouvelle route, puis finalise la route précédente au changement suivant.
Conservez malgré tout l’interaction qui a déclenché la navigation. Une transition peut sembler lente parce que son clic lance trop de JavaScript avant même le rendu du nouvel écran.
CLS : la stabilité doit être relue par étape
Le Cumulative Layout Shift (CLS) peut également être découpé entre navigations. Une route qui injecte tardivement un bandeau, un résultat ou un message d’erreur ne doit plus diluer ses déplacements dans l’ensemble de la session.
Le score ne suffit pas. Conservez la route, les éléments déplacés et le scénario. Un décalage sur un bouton de validation mérite plus d’attention qu’un mouvement équivalent sur un élément sans effet sur la tâche.
FCP et TTFB : ne pas leur faire dire la même chose
La nouvelle entrée fournit des repères de premier rendu pour la navigation douce. En revanche, il n’existe pas nécessairement une nouvelle réponse HTML dont le Time to First Byte (TTFB) pourrait devenir l’équivalent d’un chargement complet. Une route peut lire des données déjà présentes, utiliser un préchargement ou lancer plusieurs requêtes.
Documentez les temps réseau nécessaires au diagnostic, mais ne forcez pas une requête arbitraire à devenir le « TTFB de la route ».
Conserver deux séries pendant la transition
La bibliothèque officielle web-vitals version 6 ajoute la mesure des navigations douces lorsque le navigateur la supporte. Son option dédiée permet de recevoir une nouvelle mesure pour chaque route et expose notamment l’URL, le type et l’identifiant de navigation.
Le déploiement ne doit pas remplacer immédiatement l’historique. Conservez :
| Série | Périmètre | Usage | Limite actuelle |
|---|---|---|---|
| Chargements complets | tous les navigateurs compatibles avec chaque métrique | tendance historique, pages d’entrée, comparaison CrUX | ne découpe pas les routes internes d’une SPA |
| Navigations douces natives | Chromium 151+ avec l’API disponible | LCP, INP et CLS par route réelle | couverture navigateur partielle, pas encore intégrée à CrUX |
| Repli routeur ou History API | navigateurs sans API native, si l’outil le propose | page vue, durée et diagnostics personnalisés | frontière différente, LCP pas toujours disponible ou comparable |
| Laboratoire | appareil, réseau et scénario fixés | reproduction et attribution d’une cause | ne représente pas la distribution des visites réelles |
Cloudflare a par exemple annoncé le 21 août 2026 une amélioration de Web Analytics qui distingue soft-navigation lorsque l’API est disponible et utilise un repli lié aux API de routage ailleurs. Sa note de version indique que le LCP n’est pas collecté dans ce repli. C’est précisément pourquoi le champ support doit accompagner la valeur.
Une courbe unique mélangée ferait croire à une rupture de performance alors que la population ou la méthode a changé. La comparaison devient honnête lorsque chaque tableau porte sa définition.
Un protocole RUM par route en sept étapes
Le Real User Monitoring (RUM) observe les visites réelles plutôt qu’un scénario de laboratoire. Il devient utile lorsqu’il collecte assez peu de données pour rester interprétable.
- Inventorier les routes importantes et l’action complète qu’elles permettent : rechercher, comparer, enregistrer, payer ou reprendre.
- Qualifier chaque transition comme chargement complet, navigation douce native ou repli, sans fusionner ces catégories.
- Instrumenter LCP, INP et CLS avec l’URL de la métrique, son identifiant de navigation, le support et la version livrée.
- Segmenter au minimum par route, type de navigation, classe d’appareil et qualité de connexion, en évitant les segments trop petits.
- Relier la performance à une action métier sans collecter de contenu personnel : route terminée, erreur, abandon technique ou réussite.
- Diagnostiquer une route dégradée avec une trace locale, les ressources, les tâches longues et les requêtes concernées.
- Valider la correction sur le même scénario puis sur la distribution terrain, sans effacer la série précédente.
Le 75e percentile reste une lecture utile des Core Web Vitals, car il protège une majorité de visites sans laisser les appareils lents disparaître derrière la moyenne. Une route peu fréquentée peut toutefois manquer de volume. Dans ce cas, écrivez « données insuffisantes » et conservez le diagnostic de laboratoire ; ne transformez pas quelques sessions en seuil statistique.
Exemple fictif : un logiciel de suivi commercial
Imaginons un logiciel fictif avec trois routes : /clients/, /opportunites/ et /rapports/. Le chargement initial de /clients/ respecte les seuils internes. Pourtant, les utilisateurs décrivent /rapports/ comme lent après avoir choisi une période.
La première série RUM mélange toute la session sous /clients/. L’équipe active alors la mesure des navigations douces et conserve le type de support. Elle observe, sur un volume suffisant, que la transition vers /rapports/ produit un LCP plus lent sur les appareils mobiles intermédiaires. Une trace montre qu’un module de visualisation et plusieurs jeux de données sont chargés après le clic.
L’équipe ne conclut pas que « la SPA est lente ». Elle teste une correction bornée : charger seulement le résumé nécessaire au premier rendu, réserver la zone du graphique et différer le détail. Elle compare ensuite la même route, le même type de navigation et la même classe d’appareil.
Cet exemple ne promet aucun gain. Il montre la différence entre une étiquette d’architecture et une preuve localisée. La route paie le coût de ce qu’elle affiche ; le reste du produit n’a pas besoin d’être reconstruit pour corriger ce passage.
Les erreurs qui rendent les données inutiles
Remplacer les données CrUX par la nouvelle série
CrUX et Search Console ne publient pas encore ces navigations douces. Gardez leurs données comme mesure des chargements complets et comme référence publique. La série interne par route répond à une question complémentaire.
Fusionner Chrome 151, les autres navigateurs et un repli maison
Les frontières ne sont pas identiques. Un routeur peut déclarer une transition que l’API native ne détecte pas, ou inversement. Conservez la méthode et le support dans chaque événement.
Utiliser location.href au moment de l’envoi
Une métrique peut être finalisée après une nouvelle transition. L’URL courante n’est donc pas toujours l’URL à laquelle elle appartient. Utilisez l’URL et l’identifiant associés à l’entrée de navigation.
Mesurer toutes les routes sans décision associée
Un tableau de centaines d’URL ne crée pas de priorité. Commencez par les parcours qui portent une demande, un achat ou une opération importante. Pour un commerce, les priorités de performance e-commerce aident à choisir entre catégorie, recherche, fiche, panier et paiement.
Changer d’architecture pour améliorer un score
Google indique ne privilégier ni SPA ni application multipage par principe. Une migration se justifie lorsqu’elle améliore réellement l’expérience, le rendu, la maintenabilité ou le coût du changement. Notre méthode de refonte web orientée SEO et performance commence par l’inventaire et la preuve, pas par le remplacement du framework.
Quand cette mesure doit-elle déclencher un chantier ?
Une route mérite une intervention lorsque quatre conditions se rencontrent : une dégradation suffisamment observée, un effet sur une action importante, une cause plausible que l’équipe peut tester et une correction dont le résultat pourra être relu.
À l’inverse, attendez lorsque le volume est insuffisant, lorsque les navigateurs mélangés expliquent l’écart, lorsque la route a changé de périmètre ou lorsque la mesure ne conduit à aucune décision. Le bon système de suivi ne collecte pas le plus. Il raccourcit le délai entre une friction réelle et une correction vérifiable.
Commencez par une fiche simple pour cinq à dix transitions : route, action, navigation, métrique, support, version et règle d’escalade. Confrontez-la ensuite à un scénario de laboratoire sur un téléphone moyen. Cette première preuve suffit souvent à révéler si le problème vient du chargement des données, du rendu, d’un script tiers ou d’une absence de retour visible.
Vous pouvez compléter ce travail avec notre grille d’auto-audit de site puis relier la correction à une création ou refonte de site web seulement si le périmètre le justifie. Une route lente appelle d’abord un diagnostic localisé, pas une reconstruction automatique.
Sources
- Chrome for Developers — Chrome 151, date de version stable, entrées
soft-navigationetinteraction-contentful-paint. - Chrome Releases — Stable Channel Update for Desktop, annonce du déploiement desktop du 4 août 2026.
- Chrome for Developers — Measuring soft navigations, définition, attribution des URL, calcul par navigation et limites de support.
- web.dev — How SPA architectures affect Core Web Vitals, mise à jour d’août 2026, limites CrUX et autres moteurs.
- GoogleChrome/web-vitals — Changelog, prise en charge des navigations douces dans la version 6 du 21 juillet 2026.
- Cloudflare — Web Analytics improves soft navigation measurement, segmentation native et repli publiés le 21 août 2026.
