Dimension Core/Dash : type de navigation

Segmentez vos Core Web Vitals selon la façon dont vos utilisateurs arrivent sur la page pour déboguer les performances du bfcache, du prérendu et du rechargement.

Essai gratuit

Trusted by market leaders · Client results

dpg mediaadevintafotocasanina carecomparealeteiasaturnharvarderasmusmcmarktplaatshappyhorizonebaymy work featured on web.devmonarchsnvworkivanestleloopearplugsvpnkpnwhowhatwearperion

Dimension : type de navigation (nt)

Chaque vue de page dans vos données CrUX comporte un type de navigation. Il vous indique comment le navigateur a chargé la page, ce qui détermine les systèmes du navigateur impliqués : la pile réseau, le back/forward cache, le pipeline de prérendu ou une restauration de session. CoreDash expose cette information via la dimension nt pour vous permettre de filtrer et de comparer vos Core Web Vitals pour chaque contexte de navigation séparément.

Les données proviennent de l'API PerformanceNavigationTiming, plus précisément de la propriété type. Vous la lisez avec performance.getEntriesByType("navigation")[0].type. Chrome remonte cette valeur avec chaque mesure de Core Web Vitals envoyée à CrUX, et CoreDash la stocke et l'indexe pour vous permettre de segmenter vos données sans écrire d'instrumentation personnalisée.

coredash metric table urls

Pourquoi le type de navigation est important

Agréger le LCP ou l'INP sur tous les types de navigation produit un chiffre techniquement correct mais trompeur en pratique. Un hit de back/forward cache se résout en quelques millisecondes. Une navigation à froid doit attendre la résolution DNS, les connexions TCP et TLS, et le TTFB. Si 20 % de vos sessions sont des hits bfcache, elles tirent le p75 de votre LCP vers le bas et rendent un problème réel sur les navigations à froid plus difficile à détecter.

L'inverse est également vrai. Si le bfcache est cassé sur votre site, les sessions back/forward seront aussi lentes que les navigations à froid. Sans segmentation par type de navigation, vous ne le remarquerez jamais car la valeur globale reste stable.

Le prérendu est le cas le plus flagrant. Une page correctement prérendue doit afficher un LCP proche de zéro, car le rendu s'est terminé avant même que l'utilisateur ne clique sur le lien. Si vos pages prérendues affichent des valeurs de LCP normales, la configuration de vos Speculation Rules est incorrecte : le prérendu ne se déclenche pas ou est abandonné avant d'être utilisé.

Les types de navigation

navigate

Une navigation standard : l'utilisateur a saisi une URL, a cliqué sur un lien depuis un autre site ou a suivi une redirection. Il s'agit d'un chargement complet de la page, sans aucun raccourci de cache. Le navigateur traverse l'intégralité du pipeline de requêtes, y compris la résolution DNS, l'établissement de la connexion et le chargement complet des ressources. Dans les données CoreDash, navigate représente environ 65 % des sessions. C'est votre référence. Tous les autres types de navigation doivent être évalués par rapport à navigate.

reload

L'utilisateur a appuyé sur F5, a cliqué sur le bouton de rechargement du navigateur ou votre code a appelé location.reload(). Le navigateur envoie des requêtes de revalidation pour les ressources en cache, ce qui explique pourquoi le TTFB est souvent moins bon que lors d'un chargement standard, alors même que l'utilisateur est déjà sur la page. Si le TTFB de vos sessions reload est nettement supérieur à celui de navigate, vos en-têtes de cache déclenchent une revalidation à chaque rechargement au lieu de servir le contenu en cache. Environ 10 % des sessions sont des rechargements dans un trafic CoreDash typique.

back_forward

L'utilisateur a cliqué sur le bouton retour ou suivant du navigateur. Si le back/forward cache (bfcache) fonctionne, c'est le type de navigation le plus rapide possible. Le navigateur restaure la page directement depuis la mémoire sans effectuer la moindre requête réseau. Le LCP pour un hit de bfcache correspond simplement au temps de rendu depuis la mémoire, ce qui est quasi instantané.

Si vos métriques de back_forward sont similaires à celles de navigate, c'est que le bfcache ne fonctionne pas. Les causes les plus fréquentes sont les écouteurs d'événements unload, les en-têtes de réponse Cache-Control: no-store et les connexions IndexedDB restées ouvertes avant le changement de page. Les données CoreDash situent le trafic back/forward autour de 20 % des sessions, ce qui en fait un levier d'optimisation majeur.

prerender

La page a été chargée en arrière-plan à l'aide de l'Speculation Rules API avant même que l'utilisateur ne clique sur le lien. Lorsque l'utilisateur clique, le document prérendu est activé instantanément. Le LCP d'un prérendu correctement activé est proche de zéro car tout le travail de rendu s'est terminé avant l'événement de navigation.

Si votre LCP en mode prerender semble normal, l'un de ces trois cas s'est produit : le prérendu a été abandonné avant l'activation, la règle de spéculation ciblait les mauvaises URL, ou la page utilise des en-têtes ou du JavaScript bloquant le prérendu. Environ 3 % des sessions CoreDash sont des activations de prérendu, mais cette part augmente rapidement dès que les Speculation Rules sont déployées.

restore

L'onglet a été restauré après la fermeture du navigateur ou après un crash. Le navigateur recharge la page de zéro, mais la session is considérée comme une restauration (restore) plutôt que comme une navigation classique (navigate). Les performances sont similaires à celles d'une navigation à froid. Ce cas représente environ 2 % des sessions et est rarement une priorité d'optimisation, mais il mérite d'être surveillé si vos utilisateurs subissent des sessions de navigation instables.

Méthode de débogage

  1. Comparez le LCP de navigate à votre objectif global de LCP. C'est votre valeur de référence pour les performances de chargement à froid. Si navigate est déjà dans le vert, votre problème est ailleurs.
  2. Comparez back_forward à navigate. S'ils sont proches, le bfcache ne fonctionne pas. Ouvrez les Chrome DevTools, allez dans le panneau Application et lancez le test de bfcache. Le rapport listera précisément les fonctionnalités ou les en-têtes qui bloquent l'éligibilité au bfcache.
  3. Vérifiez le LCP de prerender. S'il dépasse 200 ms, le pipeline de prérendu n'est pas efficace. Validez le JSON de vos Speculation Rules, vérifiez que les pages ciblées ne renvoient aucune logique bloquante et confirmez que les activations sont bien comptabilisées dans les Chrome DevTools sous la section Speculation Rules.

Règles de base pour l'ingénierie

  • navigate : Doit respecter votre seuil de LCP via les optimisations classiques : un TTFB rapide, un attribut fetchpriority="high" sur l'image LCP, et aucune ressource render blocking.
  • back_forward : Doit être 10 à 20 fois plus rapide que navigate. Sinon, le bfcache est cassé.
  • prerender : Doit afficher un LCP inférieur à 200 ms. Sinon, vos Speculation Rules sont mal configurées.
  • reload : Le TTFB ne doit pas être significativement pire que celui de navigate. Si c'est le cas, corrigez vos en-têtes de revalidation de cache.

Le type de navigation est la dimension qui sépare « comment se comporte ma page ? » de « comment se comporte ma page selon chaque stratégie de chargement du navigateur ? ». Cette distinction fait toute la différence entre deviner et déboguer.