Une session entre directement sur la recherche, ouvre une fiche puis le panier sans recharger le document. Le collecteur envoie un seul LCP associé à la première URL ; les trois transitions suivantes disparaissent, tandis que le dashboard attribue toute l’interactivité à une page que l’utilisateur a quittée depuis plusieurs minutes.
Le problème inverse apparaît lorsqu’un routeur émet un événement à chaque changement d’état. Un filtre, un onglet et une redirection technique deviennent de fausses pages vues ; les percentiles mélangent chargement réseau, rendu partiel et interaction locale.
En pratique, un RUM SPA fiable commence par définir l’unité « navigation vécue », puis lui associe déclencheur, URL, paints, interactions et clôture. La détection native des soft navigations améliore cette cohérence, mais son déploiement Chromium et son avenir dans CrUX imposent encore une série séparée et un fallback transparent.
Vous allez concevoir ce contrat et le rattacher à notre expertise en SEO technique. Contre-intuitivement, le résultat ne doit pas être comparé directement au LCP historique du chargement : une transition réutilise shell, cache et contenu existant, donc elle décrit une expérience différente qu’il faut segmenter.
Savoir quand le RUM SPA devient indispensable
Le besoin devient critique lorsque la majorité des parcours se déroule après l’entrée initiale, que les équipes optimisent des routes internes ou que les plaintes concernent un écran dont aucun chargement dur n’existe dans les données.
Repérer les symptômes du tableau
Le premier signal faible est une page d’entrée surreprésentée dans les événements CWV par rapport aux vues internes. Le second est un INP élevé associé à l’URL initiale alors que l’interaction lente a lieu plusieurs routes plus tard.
Les SPA longues produisent aussi des sessions où le CLS cumulé augmente indéfiniment et où les versions se chevauchent après un déploiement. Sans frontière par navigation, l’équipe ne sait pas quel gabarit ni quel composant corriger en priorité.
Adapter l’investissement à la surface
Une application connectée très interactive justifie une instrumentation complète. Un site hybride dont deux filtres utilisent History API peut commencer par une mesure de transition interne et attendre la disponibilité navigateur avant d’introduire une taxonomie complexe.
Le coût complet inclut collecte, stockage, contrôle de qualité et migration des dashboards. La priorité va aux parcours dont l’absence de visibilité menace conversion, support ou capacité à attribuer une régression.
Séparer chargement dur, transition et mise à jour locale
Le chargement dur crée un document, exécute Navigation Timing et reçoit une réponse principale. La transition client conserve le document, change l’URL et peint un nouvel état après une interaction. La mise à jour locale modifie le contenu sans représenter une nouvelle destination.
Écrire une taxonomie métier
Les événements utilisent navigationType égal à hard, soft ou local. La famille de page, la route normalisée et l’action initiatrice complètent le type sans laisser le nom du framework devenir une définition utilisateur.
Un changement de tri qui modifie l’URL peut rester local si l’intention et le contenu principal ne changent pas. À l’inverse, un écran de résultat affiché sans nouvelle URL n’est pas détecté comme soft navigation native ; il peut mériter une mesure interne, clairement distincte des CWV standardisés.
Éviter les doubles comptes
Le routeur et le navigateur ne doivent pas créer deux événements pour la même transition. Le collecteur choisit la source native lorsqu’elle est supportée, puis utilise le fallback seulement dans l’autre cohorte.
Les redirections client successives sont regroupées selon une règle vérifiée. Si elles produisent plusieurs destinations visibles et paints complets, elles restent plusieurs navigations ; si elles corrigent une URL avant tout paint, seule la destination finale est rapportée.
Comprendre la détection native des soft navigations
La proposition Chrome reconnaît une soft navigation lorsque trois conditions convergent : interaction utilisateur, changement visible d’URL et paint visible de contenu. Cette heuristique vise une définition indépendante de React, Vue, Angular ou du routeur maison.
Observer les entrées en continu
Un PerformanceObserver écoute le type soft-navigation avec l’option buffered, puis traite chaque entrée dès sa réception. L’entrée fournit navigationId, interactionId, nouvelle URL et informations de paint nécessaires à l’attribution.
L’interrogation ponctuelle de getEntriesByType est insuffisante pour une application longue, car le buffer peut se limiter aux premières entrées. Le flux observé doit être copié dans un état borné puis libéré après l’envoi.
Tester faux positifs et faux négatifs
La QA joue clic de lien, retour, remplacement d’historique, filtre, modal et pagination. Elle compare ce que l’utilisateur perçoit aux marqueurs DevTools, puis documente les écarts au lieu de modifier l’heuristique avec des suppositions locales.
À la date de mise à jour, la documentation Chrome annonce une activation par défaut visée pour Chrome 151. Cette information peut encore évoluer ; le code doit utiliser la détection de fonctionnalité, jamais une déduction depuis le user-agent.
Maintenir un fallback explicite hors navigateurs compatibles
Les autres navigateurs et les anciennes versions Chromium ne produisent pas ces nouvelles entrées. Le fallback s’appuie sur les événements du routeur, l’URL, le DOM rendu et une marque de fin applicative, mais ses métriques ne sont pas étiquetées « natives ».
Détecter avant d’instrumenter
Le test vérifie la présence de soft-navigation dans PerformanceObserver.supportedEntryTypes ou l’objet SoftNavigationEntry pendant la période d’activation dynamique. Une seule branche installe ses observateurs pour éviter fuite mémoire et doublon.
La sortie porte detectionMethod égal à browser-v1 ou router-v1. Le dashboard ne fusionne ces populations qu’après une étude de biais qui compare les mêmes transitions sur des navigateurs compatibles.
Définir un contrat minimal de routeur
Le routeur signale intention, début, réussite, annulation et erreur. La fin fonctionnelle correspond au contenu principal visible et interactif, pas à la résolution d’une promesse réseau qui pourrait précéder le paint.
Un timeout clôt une transition orpheline avec status incomplete. Elle reste dans le dénominateur de qualité et ouvre une alerte ; la supprimer améliorerait artificiellement les percentiles en retirant précisément les pannes lentes.
Attribuer navigation, URL et version sans collision
Le navigationId natif identifie plusieurs visites de la même URL au sein du document. Le fallback génère un identifiant aléatoire local à la session et ne réutilise jamais un simple compteur comme clé globale.
Figer la destination observée
L’URL est normalisée vers un nom de route ou un gabarit borné ; query strings libres et identifiants sont exclus pour éviter cardinalité et données sensibles. L’URL brute peut rester dans un diagnostic local protégé, pas dans le beacon général.
La navigation conserve previousRoute, route, navigationType, detectionMethod, appVersion et sessionSequence. Ces dimensions permettent d’étudier une transition recherche-vers-produit sans créer une matrice illimitée.
Relier les entrées au bon identifiant
Pour les nouveaux paints, navigationId aide à découper la timeline, mais interaction-contentful-paint peut précéder l’émission de soft-navigation. L’interactionId associe alors le paint déclencheur à la destination correcte.
Le collecteur ne remplace pas cette règle par « URL courante au moment du callback ». PerformanceObserver peut livrer une entrée après d’autres changements ; lire location.href tardivement contaminerait la navigation suivante.
Définir le début et la clôture de chaque mesure
Le startTime natif part de l’interaction initiatrice, y compris le code exécuté par son handler. Cette définition diffère d’un chargement dur, dont le début correspond au lancement de la navigation du document.
Finaliser avant la prochaine route
Lorsqu’une nouvelle soft navigation apparaît, le collecteur clôt LCP, CLS et INP de la précédente, envoie son état puis initialise la suivante. La navigation initiale est elle aussi finalisée plus tôt que dans la méthode full-life.
Pagehide, visibilitychange vers hidden et fin de session déclenchent un flush. L’envoi est idempotent : navigationId, metricName et metricVersion forment une clé qui empêche les callbacks tardifs de doubler une valeur.
Gérer annulation et chevauchement
Si l’utilisateur clique sur une seconde destination avant le premier paint, la première transition reçoit status aborted. Le monitoring conserve durée, route cible et raison afin de distinguer impatience, erreur réseau et navigation programmée.
Une requête terminée après annulation ne doit pas alimenter le LCP suivant. Le code associe chaque ressource ou marque applicative à son identifiant et ignore les sorties dont le contexte a déjà été fermé.
Mesurer le LCP propre à la transition
Le LCP du chargement initial utilise largest-contentful-paint. Pour une soft navigation, Chrome introduit interaction-contentful-paint et la méthode de l’entrée de navigation qui restitue le plus grand paint de l’interaction déclenchante.
Calculer un temps relatif
Les timestamps restent relatifs au démarrage du document. Le calcul soustrait donc startTime de la soft navigation au temps du paint associé ; oublier cette opération ferait croître artificiellement chaque transition au fil de la session.
Seuls les paints liés à l’interactionId initiateur sont candidats. Une animation ou un clic ultérieur peut produire interaction-contentful-paint, mais ne redéfinit pas le LCP de la destination.
Interpréter le contenu réutilisé
Un hero conservé entre routes ne repeint pas et ne devient pas candidat. Le LCP soft peut donc être un titre plus petit que le LCP d’un deep link chargé directement sur cette même URL.
Cette différence n’est pas un bug : elle décrit ce que la transition a révélé à l’utilisateur. Le reporting sépare navigationType et évite de comparer directement deep link, chargement dur et route interne.
Découper CLS et INP sans contaminer les routes
Layout Shift et Event Timing fournissent des primitives pouvant être regroupées entre deux frontières. À chaque navigation, CLS et INP sont réinitialisés ; à la suivante, la valeur précédente est finalisée.
Conserver les règles de chaque métrique
Le CLS garde sa logique de fenêtres de session à l’intérieur de la tranche ; additionner tous les shifts produirait une métrique différente. L’INP retient les interactions de la période et ne rapporte pas zéro lorsqu’aucune interaction n’existe.
L’interaction qui déclenche la nouvelle route appartient au début de cette route selon la définition soft. Ce choix est documenté afin de ne pas la compter aussi dans l’INP de la destination précédente.
Traiter les tâches transverses
Une tâche lancée par l’ancien écran peut déborder après le changement de route. Son événement garde navigationId et version d’origine lorsque la plateforme les fournit ; le fallback s’appuie sur marques et contexte capturé, jamais sur l’URL courante.
La mémoire et les listeners accumulés au fil des routes peuvent dégrader les interactions tardives. Le RUM conserve sessionSequence pour révéler une hausse entre première et dixième navigation sans créer un budget arbitraire par URL.
Interpréter TTFB, réseau et données préchargées
Une soft navigation n’a pas de réponse document principale. Quelle requête choisir si les données viennent du cache, si elles ont été préchargées ou si plusieurs appels concourent au contenu ?
Ne pas fabriquer un TTFB HTTP
La bibliothèque web-vitals officielle rapporte actuellement un TTFB de zéro pour les soft navigations. Cette convention distingue l’absence de navigation réseau ; elle ne prouve pas que les données ont été instantanées.
Le dashboard conserve TTFB soft séparé du chargement dur. Mélanger les zéros avec les réponses document réduirait artificiellement le percentile d’infrastructure.
Ajouter un diagnostic applicatif nommé
L’équipe peut mesurer dataReady ou routeDataDuration depuis l’interaction jusqu’à la disponibilité des données nécessaires. Cette métrique interne documente cache hit, prefetch, requêtes et erreur, mais ne doit pas être appelée TTFB ni CWV.
Resource Timing aide à attribuer les appels réseau lorsqu’ils existent. Le contrat précise sélection, initiateur et cache ; une requête analytics ne devient pas le « premier byte » de la route parce qu’elle a terminé la première.
Concevoir un beacon idempotent et économe
Une application longue peut produire des dizaines de transitions et plusieurs mises à jour par métrique. Le collecteur agrège en mémoire un état borné, puis émet une ligne finale par navigation et par métrique.
Définir le schéma
L’entrée contient navigationId, navigationType, detectionMethod, route, previousRoute, version, metric, value, rating interne, startTime relatif, status, deviceClass et niveau de couverture. La sortie exclut URL libre et attributs de contenu.
Le serveur valide types, plages, taille et version de schéma. Une clé d’idempotence refuse les retries identiques ; un horodatage de réception ne remplace jamais le temps navigateur pour ordonner les transitions.
Protéger coût et confidentialité
L’échantillonnage est stable par session afin de conserver les séquences complètes. Une surreprésentation volontaire des erreurs est stockée dans une strate distincte et pondérée, sinon elle fausse les percentiles.
SendBeacon ou fetch keepalive transporte un petit lot à la clôture. Le monitoring suit perte, rejet de schéma, volume et latence d’ingestion ; si la couverture sort de sa plage, alors le verdict devient indéterminé.
L’instrumentation prend en entrée l’état finalisé et le seuil de taille ; sa sortie passe par une file de transport dotée d’un retry borné. La journalisation du serveur conserve l’identifiant d’idempotence pour distinguer rejet, doublon et perte réseau.
Le runbook associe le monitoring de couverture à une responsabilité d’astreinte et à un repli vers la série full-life. Si la dépendance d’ingestion échoue, alors le pipeline suspend les alertes soft au lieu de publier des percentiles incomplets.
Conserver deux séries comparables pendant la transition
Chrome recommande de maintenir la méthode traditionnelle et la découpe soft afin de comparer navigateurs et histoire. LCP initial reste mesuré comme auparavant ; CLS et INP full-life continuent à côté des valeurs par transition.
Nommer les séries sans ambiguïté
Les tables portent measurementMode égal à page-lifecycle ou soft-navigation. Aucun dashboard ne calcule un percentile commun tant que support navigateur, attribution et distribution des routes ne sont pas alignés.
La baseline traditionnelle ne disparaît pas à la première activation. Un pont de plusieurs semaines mesure couverture, faux positifs, divergences et comportement par version avant de décider quels usages opérationnels migrent.
Ne pas anticiper CrUX
À la date de mise à jour, Chrome indique que la manière exacte de publier les soft navigations dans CrUX reste à déterminer. Le RUM interne ne doit donc pas prétendre reproduire dès maintenant la donnée officielle future.
La comparaison à Search Console ou CrUX reste fondée sur chargements et agrégations disponibles, avec ses limites déclarées. La série soft sert à améliorer les routes internes et à préparer l’évolution sans réécrire l’historique public.
Relier performances et invariants de routage SEO
Mesurer une transition ne garantit ni crawl ni indexation. Chaque URL destinée à la recherche doit rester accessible par un lien, produire un rendu exploitable, exposer canonical cohérent et répondre correctement en accès direct.
Comparer deep link et transition
La QA ouvre la destination par chargement dur puis l’atteint depuis la SPA. Elle compare contenu principal, titre, canonical, données structurées, liens, statut et erreurs d’hydratation.
Une route interne rapide mais vide en SSR déplace la performance au prix de l’indexabilité. À l’inverse, un deep link correct peut subir une transition client lente ; les deux chemins possèdent leurs propres preuves.
Instrumenter sans cardinalité SEO
Le nom de gabarit et le statut indexable attendu suffisent au RUM. Les mots-clés, requêtes libres et identifiants de contenu n’ont pas besoin d’être envoyés pour relier une régression à une famille organique.
Les logs de Googlebot observent principalement des requêtes document et ne doivent pas être mélangés aux transitions humaines. Leur rapprochement se fait au niveau route, version et fenêtre de release.
Simuler une session de quatre routes
Cas concret : une session charge recherche en 2,1 secondes de LCP, puis ouvre produit, panier et paiement. L’ancien collecteur envoie un seul LCP recherche et un INP full-life de 310 millisecondes associé à cette URL initiale.
Découper les transitions
La détection native attribue produit 1,4 seconde de LCP soft et 120 millisecondes d’INP. Panier obtient 900 millisecondes et 180 ; paiement obtient 1,8 seconde et 320, après une longue tâche de validation.
Le TTFB soft reste zéro par convention, tandis que routeDataDuration du paiement vaut 640 millisecondes. La comparaison montre que le réseau ne suffit pas : 410 millisecondes proviennent ensuite du rendu et de la validation JavaScript.
Prendre une décision reproductible
L’équipe fixe une alerte interne si INP soft paiement dépasse 250 millisecondes sur au moins 5 000 transitions et deux fenêtres quotidiennes. Ces seuils sont un scénario simulé, pas une recommandation universelle.
Le correctif fractionne la validation et réduit le p75 à 190 millisecondes sans baisse de couverture. La série full-life reste publiée : elle passe de 310 à 230 et confirme que l’amélioration locale influence l’expérience de session.
Éviter les erreurs fréquentes d’instrumentation
La première erreur est de marquer navigationStart à la fin du fetch. Elle supprime attente réseau et handler, puis produit une transition artificiellement rapide qui ne correspond pas au clic de l’utilisateur.
Refuser URL courante et métriques recomposées
Lire location.href au moment de l’envoi peut attribuer une entrée retardée à la route suivante. L’identité est capturée sur l’événement et propagée jusqu’au beacon.
Une autre erreur appelle LCP le plus grand élément trouvé par MutationObserver. Sans primitives de paint du navigateur, il s’agit d’un indicateur interne dont la sémantique et les limites doivent porter un autre nom.
Ne pas fusionner trop tôt
Soft natif, fallback routeur, full-life et chargement dur décrivent des périmètres différents. Les moyenner produit un chiffre élégant mais impossible à diagnostiquer ou à comparer à CrUX.
Enfin, une navigation sans interaction ultérieure ne reçoit pas un INP de zéro dans la méthode officielle. Ajouter ces zéros abaisserait mécaniquement le percentile et récompenserait les écrans que personne n’utilise.
Plan d’action : industrialiser le RUM en six semaines
Le déploiement commence par deux parcours longs et un gabarit hybride. Il doit prouver les frontières, l’idempotence et le diagnostic avant d’étendre les nouveaux événements à toute l’application.
Semaines 1 à 3 : taxonomie, prototype et qualité
La première semaine cartographie chargements, soft navigations et mises à jour locales. Elle fixe routes bornées, actions initiatrices, statuts de clôture et métriques internes qui ne doivent pas être appelées CWV.
La deuxième installe PerformanceObserver derrière feature detection et un fallback routeur versionné. L’instrumentation produit navigationId, URL figée, startTime, interactionId, méthode et version.
La troisième teste clic, retour, replaceState, annulation, double navigation, visibilité et session longue. DevTools, logs du routeur et beacons sont rapprochés pour compter faux positifs et faux négatifs.
Semaines 4 à 6 : double série, canari et décision
La quatrième branche LCP soft, CLS, INP et diagnostics réseau en conservant les calculs full-life. Elle teste les timestamps relatifs et le mapping par interactionId.
La cinquième ouvre un canari Chromium, mesure couverture et écart avec le fallback, puis vérifie le deep link SEO de chaque route. Un seuil de collecte insuffisant suspend tout verdict.
La sixième publie les deux séries, leurs définitions et les premières alertes locales. L’extension dépend d’un beacon idempotent, d’un coût réseau borné et d’un runbook pour API absente ou transition orpheline.
- Classer chaque changement d’écran comme hard, soft ou local avant d’émettre une métrique.
- Utiliser la détection native par fonctionnalité et garder le fallback dans une cohorte séparée.
- Figer identifiant, URL, interaction et début au moment de la navigation, jamais lors du callback tardif.
- Finaliser la route précédente avant d’initialiser LCP, CLS et INP de la suivante.
- Maintenir full-life et soft en parallèle jusqu’à une décision explicite sur leurs usages.
- Contrôler deep links, rendu HTML, canonicals et liens indépendamment de la vitesse de transition.
Guides complémentaires et sources primaires
Cette surface évolue rapidement. La documentation Chrome et les dépôts de spécification sont les références à relire avant chaque changement d’implémentation ou de politique de reporting.
Suivre la forme courante des API
La documentation Chrome sur la mesure des soft navigations détaille critères de détection, navigationId, interactionId, timestamps, LCP de transition, double série et support visé. Elle indique aussi que le reporting CrUX reste à définir.
Le dépôt WICG Soft Navigations porte la proposition et ses discussions. Le billet officiel sur le dernier origin trial explique les changements de forme testés en 2026.
S’appuyer sur la bibliothèque sans masquer le contrat
La bibliothèque officielle web-vitals prend en charge le reporting soft depuis sa version 6 et gère plusieurs nuances d’attribution. Votre schéma, vos routes et votre double stockage restent toutefois à gouverner localement.
Pour compléter, la segmentation RUM par gabarit structure les cohortes, tandis que le diagnostic entre CrUX, RUM et Lighthouse empêche de comparer des périmètres incompatibles.
- Vérifier la forme courante de l’API et détecter sa présence au lieu de cibler un numéro de navigateur.
- Versionner le schéma, la méthode de détection et le calcul avant toute comparaison de percentiles.
- Conserver les séries full-life, soft native et fallback séparées tant que leurs biais ne sont pas qualifiés.
Conclusion : mesurer l’expérience réellement vécue
Une SPA ne crée pas un nouveau document à chaque écran, mais l’utilisateur vit bien des destinations successives. Le RUM doit leur donner une identité, une frontière et des métriques sans falsifier le chargement initial.
La détection native apporte une définition commune et de nouvelles primitives de paint. Son support partiel et le reporting CrUX encore ouvert imposent feature detection, double série et libellés explicites.
LCP soft, CLS découpé, INP par tranche et diagnostic réseau répondent à des questions distinctes. Leur attribution correcte dépend davantage du cycle de vie et de l’idempotence que du volume de données envoyé.
Pour cartographier les transitions, instrumenter les bonnes primitives et relier chaque route à une preuve technique et SEO, notre accompagnement en SEO technique construit un RUM SPA comparable, actionnable et prêt à évoluer avec la plateforme.
