Une application charge une seule page HTML, puis enchaîne fiche, panier et compte sans navigation document. Le tableau RUM réinitialise le CLS à chaque changement d’URL et annonce des routes stables, alors que l’utilisateur subit plusieurs déplacements, perd sa position de lecture et peut activer le mauvais bouton pendant une même visite.
Le navigateur ne crée pas automatiquement un nouveau Core Web Vital pour chaque transition gérée par JavaScript. Le CLS natif observe la durée de vie du document ; CrUX ne transforme pas aujourd’hui chaque route virtuelle en nouvelle page comparable à une navigation classique. Ce désaccord rend le diagnostic urgent dès que le produit pilote ses équipes par route.
En réalité, la vraie question consiste à construire une attribution interne par route sans rebaptiser cette valeur « CLS officiel ». La frontière, les mouvements retenus et les transitions annulées doivent être explicites pour conserver une comparaison honnête.
Notre accompagnement en SEO technique relie routeur, PerformanceObserver et cycle de rendu. Contre-intuitivement, remettre le compteur à zéro au clic peut améliorer le tableau tout en attribuant les mouvements de l’ancienne route à la nouvelle.
Comprendre pourquoi le CLS natif ne repart pas à zéro
Une SPA conserve le même document lors des transitions client. Les entrées layout-shift continuent donc sur une seule timeline, comme les autres événements de cette page.
Distinguer page vue et document
L’analytics peut émettre une page vue à chaque URL, mais cette convention métier ne change pas les API du navigateur. Une métrique interne découpe la timeline ; elle ne crée pas une nouvelle navigation physique.
Le rapport garde le CLS natif du document, puis ajoute une valeur « shift score de route ». Ce vocabulaire empêche de comparer directement le second à CrUX ou aux seuils officiels.
Conserver la fenêtre de session officielle
Le CLS utilise la fenêtre de décalages la plus forte, séparée par des intervalles définis. Une somme par route qui ignore ces fenêtres peut dépasser ou sous-estimer la métrique du document.
La reconstruction interne réutilise les mêmes règles lorsqu’elle veut produire un score analogue, mais documente le découpage supplémentaire lié au routeur.
Savoir quand créer une mesure par route
La mesure devient utile lorsque les équipes déploient et possèdent les routes séparément, que les sessions parcourent plusieurs écrans et que le CLS document ne permet pas d’attribuer la régression.
Relier le score à une décision
Une équipe produit doit pouvoir corriger un skeleton de fiche sans attendre la fin de toutes les sessions. La métrique de route apporte route, version, sources et volume nécessaires au triage.
Si l’application comporte seulement une transition rare, l’instrumentation complexe peut coûter plus que l’analyse manuelle. Le bon arbitrage dépend du nombre de routes, des releases et de la fréquence des parcours longs.
Refuser la comparaison trompeuse
Le score interne sert à comparer une route avec elle-même, sur la même convention et la même version. Il ne remplace pas le p75 Core Web Vitals de l’origine.
Le dashboard affiche définition, couverture et dénominateur près de la valeur. Une route virtuelle « bonne » n’autorise pas à annoncer un CLS officiel sous 0,1.
Définir une frontière de navigation défendable
Le clic est trop tôt si l’ancienne route continue à fermer une modale ; l’URL est trop tard si le nouveau DOM bouge avant pushState. La frontière suit le contrat réel du routeur.
Identifier début, engagement et fin
Le début capture l’intention utilisateur et un identifiant de transition. L’engagement survient lorsque le routeur accepte la destination. La fin correspond à un état rendu défini, pas nécessairement à la fin de toutes les requêtes secondaires.
Le contrat associe URL précédente, destination normalisée, navigation initiée par utilisateur ou programme, état annulé et horodatages haute résolution.
Choisir l’instant d’attribution
Les mouvements avant l’engagement restent attachés à l’ancienne route. Ceux provoqués par le nouveau skeleton rejoignent la destination. Une courte zone d’ambiguïté est marquée « transition » plutôt que forcée arbitrairement.
Cette troisième catégorie révèle les routeurs qui effacent trop tôt l’ancien contenu. Elle devient un signal de correction, pas une poubelle statistique.
Reconstruire les fenêtres sans réécrire la métrique
Le collecteur observe toutes les entrées de layout et conserve valeur, instant, sources et hadRecentInput. Il groupe seulement celles comprises entre les frontières retenues.
Appliquer une règle stable
Pour chaque route, la logique recherche la plus forte fenêtre selon les intervalles officiels, puis publie score, somme brute et nombre de mouvements. Les mêmes tests unitaires couvrent chaque framework.
La convention ne change pas selon le résultat. Ajuster la fin de route pour réduire un écran lent détruit la comparabilité historique.
Fermer les routes longues
Une route reste active jusqu’à la prochaine transition ou à la fin du document. Les mises à jour temps réel peuvent donc créer une fenêtre tardive, pertinente pour l’utilisateur.
Le rapport distingue phase initiale et vie longue sans exclure cette dernière du CLS document. Les équipes voient si le défaut appartient au chargement ou aux mises à jour.
Attribuer les mouvements à la bonne route
Les sources indiquent les nœuds déplacés, mais un conteneur de l’ancienne route peut encore exister pendant la transition. Une génération de vue marque les racines et leur destination.
Tracer les générations DOM
Le routeur associe un identifiant borné au conteneur rendu. L’observateur rapproche la source du parent le plus proche, sans stocker le libellé ni les données utilisateur.
Si plusieurs racines coexistent, la valeur reste dans la catégorie transition. Le système ne double pas le même mouvement dans deux routes.
Conserver le composant responsable
Une source affectée n’est pas toujours le déclencheur. La trace de rendu relie l’insertion du skeleton, l’image sans dimensions ou la police tardive à l’instant du mouvement.
Route, composant, version et famille de cause suffisent à ouvrir une action. Les sélecteurs uniques ou contenus personnels restent exclus de la télémétrie.
Gérer transitions concurrentes et navigations annulées
Un double clic, un retour navigateur ou une redirection de garde peut démarrer une destination puis l’abandonner. Une mesure naïve laisse son score attaché à l’écran final.
Modéliser un automate
Chaque transition porte les états créée, engagée, rendue, annulée ou échouée. Une nouvelle intention annule explicitement la précédente et ferme sa fenêtre avec son motif.
Les mouvements d’une vue abandonnée restent visibles dans une cohorte « annulée ». Ils représentent une vraie souffrance, même s’ils ne doivent pas contaminer la route réussie.
Traiter retour et redirection
Le bouton précédent, une navigation de canonicalisation côté client ou une redirection de contrôle d’accès peuvent changer la route affichée. L’identifiant de navigation relie les étapes sans créer plusieurs pages vues fictives.
Le monitoring alerte sur le taux d’annulation, car une hausse peut révéler une API lente ou un routeur instable avant même la dégradation du score.
Mesurer skeleton, données et hydratation
La route virtuelle peut d’abord rendre un skeleton, puis les données et enfin des widgets. Chacune de ces phases déplace le layout si son empreinte n’est pas contractuelle.
Définir une sortie de route utile
Le jalon « contenu principal prêt » correspond au titre, à la zone d’action et à la structure stable. Les recommandations ou compteurs temps réel restent après cette sortie, mais leurs mouvements demeurent observés.
Le contrat ne dépend pas de networkidle, souvent inatteignable avec analytics et flux persistants. Il utilise des événements du produit testables.
Réserver la géométrie
Images, cartes, messages et barres d’action possèdent dimensions avant les données. Le skeleton reproduit la grille finale plutôt qu’une approximation décorative.
Le rendu SSR de la première route et le rendu client des suivantes partagent les mêmes composants. Cette parité évite une stabilité correcte au chargement mais mauvaise après navigation.
Comparer mesure interne et Core Web Vital
Le RUM conserve deux familles : CLS du document et score interne des routes. Les agrégations, seuils et libellés restent séparés.
Documenter la couverture
Le rapport indique navigateurs, version du collecteur, routes instrumentées, transitions sans frontière et part de sessions multi-routes. Une valeur inconnue n’est pas classée à zéro.
CrUX couvre des visites Chrome éligibles et ne fournit pas cette segmentation de route virtuelle. La divergence est attendue ; elle doit être expliquée, pas corrigée artificiellement.
Décider avec plusieurs signaux
Le score de route accompagne temps de transition, erreurs, annulations et conversion sans confondre corrélation et causalité. Le CLS document garde le rôle de garde-fou externe.
La priorité combine trafic de route, valeur du parcours, taille de l’écart et confiance d’attribution. Une route rare mais bloquante peut passer avant une petite dérive de l’accueil.
Rejouer les parcours plutôt qu’une page isolée
Une navigation Lighthouse classique ne couvre pas les mouvements après plusieurs transitions. Les user flows et tests navigateur reproduisent arrivée, clic, retour et route lente.
Construire une matrice de parcours
Le QA teste accueil vers liste, liste vers fiche, fiche vers panier, retour et redirection d’authentification. Il varie cache, viewport, CPU et réponse API.
Chaque étape capture sources de déplacement, génération DOM, URL et jalon de rendu. Une capture visuelle confirme que le score bas ne masque pas un contenu invisible.
Tester l’instrumentation elle-même
Les tests injectent une entrée avant, pendant et après frontière, puis vérifient son attribution. Ils simulent deux transitions concurrentes et une annulation.
La CI contrôle aussi routes SSR, canonical, HTML, liens, hydratation et erreurs JavaScript. Googlebot doit recevoir le contenu utile sans dépendre du routeur client.
Déployer l’instrumentation sans casser le routeur
Le collecteur commence en mode miroir : il publie sans déclencher d’alerte. Les équipes comparent timeline brute et attribution sur un échantillon relisible.
Versionner la convention
Un changement de frontière ou de fenêtre reçoit une version et une date. Les séries incompatibles ne sont pas fusionnées dans le même graphique.
Le responsable performance possède la définition ; l’équipe plateforme RUM possède collecte et cardinalité ; chaque squad possède ses routes. Le contrat précise responsabilités, seuils et rétention.
Préparer le repli
Un drapeau désactive l’attribution sans désactiver l’observation native. Le rollback ne touche ni routeur ni rendu utilisateur.
La généralisation exige couverture, coût CPU et volume réseau sous budget. Une métrique précise mais trop lourde ne doit pas devenir une nouvelle cause d’INP.
Décider avec un cas chiffré entièrement simulé
Cas concret entièrement simulé : une SPA fictive reçoit 140 000 sessions hebdomadaires, dont 62 % parcourent au moins trois routes. Le CLS document p75 vaut fictivement 0,21 ; ce seuil oblige l’équipe à bloquer la release au-dessus de 0,18. Ces données ne proviennent d’aucun client.
Isoler une route panier
L’attribution simulée mesure 0,03 sur liste, 0,05 sur fiche et 0,17 sur panier. Le panier remplace un skeleton de deux lignes par cinq lignes après 900 ms, puis affiche un coupon tardif.
Le correctif fixe la grille et réserve le message promotionnel. La frontière reste l’engagement du routeur, vérifiée sur clic et retour.
Valider les seuils fictifs
Sur 22 000 parcours simulés, le panier descend à 0,06 et le CLS document à 0,12. Les transitions annulées restent à 0,14, ce qui ouvre un lot séparé.
Le contrat fictif bloque une route au-dessus de 0,10 avec 5 000 vues et arrête le collecteur au-delà de 4 ms CPU p75. Ces seuils illustrent la méthode et exigent un calibrage réel.
Éviter les erreurs fréquentes de remise à zéro
La première erreur fixe le début à chaque pushState sans distinguer navigation produit et mise à jour de filtre. Le nombre de routes explose et les scores deviennent minuscules.
Ne pas supprimer l’histoire du document
Le score interne n’efface jamais le CLS natif. Présenter seulement des routes vertes masque l’expérience cumulée des sessions longues.
Une autre erreur ignore les mouvements tardifs après le jalon « prêt ». Ils restent vécus et doivent appartenir à la route active.
Ne pas confondre expérimentation et standard
Les API de soft navigation ont évolué et leur disponibilité doit être vérifiée dans l’environnement cible. Une fonctionnalité expérimentale ne constitue pas seule un contrat de production universel.
Enfin, nommer la valeur « CLS par page » crée une fausse équivalence. Un libellé précis protège la gouvernance autant que le code.
Plan d’action : fiabiliser le RUM en trois semaines
Le pilote sélectionne trois parcours et une version du routeur. Performance, frontend, analytics, QA et produit partagent les timelines brutes.
Semaine 1 : définir et contredire
L’équipe écrit automate, frontières, catégories transition et convention de fenêtre. Elle rejoue mouvements artificiels et vérifie l’attribution.
Les routes, annulations et couvertures sont inventoriées. Les libellés du dashboard séparent métrique interne et Core Web Vital.
Semaines 2 et 3 : instrumenter et ouvrir
L’entrée associe route, transition et sources ; la sortie publie score, couverture et version. Instrumentation, monitoring, seuils, dépendances, journalisation et rollback sont testés.
La CI couvre SSR, hydratation, canonical, crawl et indexation. Le mode miroir devient canari, puis s’étend si coût et attribution restent stables.
D’abord, la performance sélectionne vingt timelines qui couvrent clic simple, retour et annulation. Ensuite, le frontend compare chaque frontière à la génération DOM et le QA injecte des mouvements aux trois moments limites. Puis, l’analytics vérifie que page vue et identifiant de transition ne se dédoublent pas. Le passage en alerte attend 98 % de transitions classées sur au moins 10 000 parcours.
Le contrat de sortie bloque la version si plus de 1 % des mouvements restent sans route, si le collecteur dépasse 4 ms de CPU p75 ou si une annulation rejoint la destination finale. Le repli désactive uniquement l’attribution interne, conserve l’observation native et restaure le tableau précédent sans modifier le routeur.
Passer du miroir aux alertes
La généralisation compare ensuite trois cohortes de 25 000 transitions, avec un intervalle identique entre les lots. Si la couverture recule de deux points ou si le score panier dépasse 0,10, le responsable diffère le lot suivant ; sinon il étend route par route en conservant la version de convention.
Chaque alerte contient l’identifiant de build, la frontière appliquée, le nombre de mouvements, la part annulée et la dépendance du routeur. Cette sortie permet au frontend de reproduire le défaut sans demander un export nominatif à l’équipe data.
Un dernier contrôle relie dix alertes au film de la transition, au DOM produit et à la page vue analytique. Le responsable accepte le passage en production uniquement si les trois traces désignent la même frontière et si le score recalculé diffère de moins de 0,01. Toute divergence rouvre l’échantillon, gèle la cohorte suivante et conserve la métrique native comme référence publique.
Par exemple, avant l’ouverture complète, la performance rejoue encore cent transitions sur mobile contraint et vingt sur retour arrière. Elle compare nombre de sources, fenêtre retenue, score de route et CLS du document, puis bloque si une transition dépasse 0,10 ou si la couverture descend sous 98 %. Ce lot final prouve que l’alerte déclenche une décision reproductible, pas seulement un graphique enrichi.
- D’abord, conserver le CLS du document intact.
- Ensuite, nommer les frontières du routeur.
- Puis, attribuer transitions annulées séparément.
- À valider seulement : une convention testée par parcours.
- Enfin, décider l’alerte après une période miroir.
Guides complémentaires et sources primaires
Les sources officielles cadrent les entrées de layout et les limites de mesure des applications à document unique.
Vérifier définition et SPA
La spécification Layout Instability définit les entrées. Google explique les effets des architectures SPA sur les Core Web Vitals.
L’analyse officielle des écarts entre CrUX et RUM précise les limites des routes virtuelles.
Relier les causes
Le travail sur la personnalisation tardive borne les composants. L’analyse du header dynamique après authentification traite une cause fréquente.
- Garder une chronologie unique opposable.
- Versionner la convention de route.
- Comparer uniquement des séries compatibles.
Conclusion : nommer une métrique interne honnête
Une SPA ne crée pas une nouvelle page navigateur à chaque route. Son CLS officiel reste attaché au document et raconte l’expérience cumulée.
Une attribution par route reste précieuse si ses frontières, annulations et fenêtres sont explicites. Elle transforme un symptôme global en composant corrigeable.
Le mode miroir, les tests de parcours et la version de convention empêchent un faux reset de verdir le tableau. La mesure sert alors la décision sans usurper le standard.
Pour instrumenter vos transitions, rapprocher RUM et traces puis sécuriser vos routes, notre accompagnement en SEO technique vous aide à piloter la stabilité d’une SPA avec des preuves honnêtes.
