Core Web Vitals des SPA : enfin mesurer les parcours internes

Les Core Web Vitals des SPA sont longtemps restés difficiles à observer au-delà du premier chargement. Or, dans une application métier, le moment décisif se produit souvent après : ouvrir un dossier, filtrer une liste, passer au paiement ou enregistrer une modification. Chrome 152 fait évoluer ses outils de performance pour remonter LCP et INP lors de ces navigations internes. C’est une occasion de mesurer l’expérience telle qu’elle est réellement vécue, parcours par parcours.

Ce qui change pour les applications à navigation côté client

Une SPA ne recharge pas le document à chaque changement d’écran. Cette fluidité apparente peut pourtant masquer une attente : données lentes, composants lourds, calculs sur le thread principal ou images arrivant tardivement. Dans Chrome 152, la vue Live Metrics de DevTools prend en charge par défaut les Core Web Vitals des « soft navigations », avec la bibliothèque web-vitals 6.0.0. Il devient plus simple d’observer une navigation interne sans l’assimiler au chargement initial.

Cette évolution ne transforme pas automatiquement chaque changement d’URL en mesure parfaite ni chaque métrique locale en donnée terrain. Elle donne en revanche un signal de diagnostic plus proche du produit : quel écran ou quelle transition mérite une investigation avant qu’un ralentissement ne coûte des erreurs, des abandons ou des appels au support ?

Mesurer un parcours utile, pas seulement une page

La bonne unité de travail est un scénario concret. Pour un portail client : se connecter, retrouver une facture, ouvrir son détail, la télécharger. Pour un back-office : filtrer des dossiers, ouvrir une fiche, modifier un statut, revenir à la liste. Le test commence avec des données représentatives et une connexion volontairement réaliste ; il ne s’arrête pas au score global de la page d’accueil.

Un exemple de lecture

Si l’ouverture d’une fiche affiche rapidement sa structure mais bloque la première interaction, l’INP invite à examiner les traitements JavaScript, les rendus inutiles et les appels déclenchés simultanément. Si le contenu principal arrive tard, le LCP oriente plutôt vers la donnée critique, le découpage de code ou la priorité des ressources. L’objectif n’est pas d’optimiser un chiffre isolé : c’est de raccourcir une étape importante du travail.

Une méthode pragmatique en quatre temps

1. Choisir trois parcours à enjeu : conversion, action fréquente et opération sensible.
2. Reproduire chaque navigation interne dans DevTools en relevant le moment précis où l’utilisateur attend.
3. Corriger une cause à la fois : chargement différé d’un module, requête inutile, rendu trop large ou ressource non priorisée.
4. Recontrôler puis instrumenter les parcours réellement critiques en production, sans collecter de données personnelles dans les mesures.

Garder la performance au service du produit

Les métriques de laboratoire révèlent des pistes ; elles ne remplacent ni l’observation d’utilisateurs ni les données de terrain. Une optimisation est réussie lorsqu’elle rend une tâche plus prévisible : l’utilisateur sait que sa sélection est prise en compte, qu’une donnée arrive, et qu’une action importante n’a pas été perdue. À l’inverse, précharger sans discernement peut déplacer le problème vers le réseau ou le coût d’exploitation.

La note officielle Chrome DevTools 152 détaille cette prise en charge des soft navigations et les autres nouveautés de la version, publiée le 25 août 2026.