Dimension CoreDash : Navigation Type

Segmentez vos Core Web Vitals en fonction de la manière dont les utilisateurs sont arrivés sur la page pour déboguer les performances du bfcache, du prerender et du reload.

Essai gratuit

Trusted by market leaders · Client results

aleteiamy work featured on web.devadevintaloopearplugsnina careharvarderasmusmcnestlemonarchmarktplaatssnvebayperionfotocasahappyhorizonwhowhatweardpg mediacomparekpnsaturnvpnworkiva

Dimension : Navigation Type (nt)

Chaque vue de page dans vos données CrUX porte 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 prerender ou une restauration de session. CoreDash expose cela via la dimension nt afin que vous puissiez filtrer et comparer les Core Web Vitals pour chaque contexte de navigation séparément.

Les données proviennent de l'API PerformanceNavigationTiming, spécifiquement la propriété type. Vous la lisez avec performance.getEntriesByType("navigation")[0].type. Chrome rapporte cette valeur aux côtés de chaque mesure de web vitals envoyée à CrUX, et CoreDash la stocke et l'indexe pour que vous puissiez segmenter sans écrire d'instrumentation personnalisée.

coredash metric table urls

Pourquoi le Navigation Type est important

L'agrégation du LCP ou de l'INP sur tous les types de navigation produit un nombre qui est techniquement correct mais pratiquement trompeur. Un succès du back/forward cache se termine en quelques millisecondes. Une navigation à froid attend le DNS, TCP, TLS et le TTFB. Si 20 % de vos sessions sont des succès bfcache, elles tirent votre p75 LCP vers le bas et rendent un problème réel sur les nouvelles navigations plus difficile à voir.

L'inverse est également vrai. Si le bfcache est défaillant sur votre site, les sessions back/forward seront aussi mauvaises que les nouvelles navigations. Sans segmentation par type de navigation, vous ne le remarquerez jamais, car l'agrégat reste stable.

Le prerender est le cas le plus spectaculaire. Une page correctement pré-rendue (prerendered) devrait 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 chiffres LCP normaux, la configuration des Speculation Rules est incorrecte et le prerender n'est soit pas déclenché, soit rejeté avant utilisation.

Les Navigation Types

navigate

Une navigation standard : l'utilisateur a tapé une URL, cliqué sur un lien provenant d'un autre site ou suivi une redirection. Il s'agit d'un chargement complet de la page sans raccourcis de mise en cache. Le navigateur passe par tout le pipeline de requête, y compris la recherche 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 base de référence (baseline). Tout autre type de navigation doit être jugé par rapport à sa comparaison avec navigate.

reload

L'utilisateur a appuyé sur F5, 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 mises en cache, ce qui signifie que le TTFB semble souvent moins bon qu'une navigation alors que l'utilisateur est sur la même page. Si votre TTFB reload est considérablement plus élevé que votre TTFB navigate, vos en-têtes de cache déclenchent une revalidation à chaque rechargement au lieu de servir du contenu périmé. Environ 10 % des sessions sont des rechargements dans le trafic typique de CoreDash.

back_forward

L'utilisateur a appuyé sur le bouton précédent 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 depuis la mémoire sans aucune requête réseau. Le LCP pour un succès bfcache est effectivement le temps de peindre (paint) depuis la mémoire, ce qui est quasi instantané.

Si vos métriques back_forward ressemblent à celles de navigate, le bfcache ne fonctionne pas. Les causes les plus courantes sont les gestionnaires d'événements unload, les en-têtes de réponse Cache-Control: no-store et les connexions IndexedDB ouvertes qui n'ont pas été fermées avant la navigation. Les données CoreDash placent le back/forward à environ 20 % des sessions, ce qui en fait un correctif à fort impact.

prerender

La page a été chargée en arrière-plan à l'aide de l'API Speculation Rules avant que l'utilisateur ne clique sur le lien. Lorsque l'utilisateur clique, le document pré-rendu est activé instantanément. Le LCP pour un prerender 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 prerender semble normal, l'une de ces trois choses s'est produite : le prerender a été rejeté avant l'activation, la règle de spéculation ciblait les mauvaises URL, ou la page utilise des en-têtes ou du JavaScript qui empêchent le prerendering. Environ 3 % des sessions CoreDash sont des activations de prerender, mais cette part augmente rapidement une fois que les Speculation Rules sont déployées.

restore

L'onglet a été restauré après la fermeture du navigateur ou le plantage de l'onglet. Le navigateur recharge la page à partir de zéro, mais la session est considérée comme une restauration plutôt qu'une nouvelle navigation. Les performances sont similaires à une navigation à froid. Cela représente environ 2 % des sessions et c'est rarement le point central du travail d'optimisation, mais cela vaut la peine d'être surveillé si vous avez des utilisateurs sur des sessions de navigateur instables.

Workflow de débogage

  1. Comparez le LCP navigate à votre objectif global de LCP. C'est votre vérité terrain pour les performances de chargement à neuf. Si le type navigate passe déjà, votre problème est ailleurs.
  2. Vérifiez back_forward par rapport à navigate. S'ils sont proches, le bfcache est défaillant. Ouvrez Chrome DevTools, allez dans le panneau Application et lancez le test bfcache. La sortie des DevTools listera exactement quelles fonctionnalités ou quels en-têtes bloquent l'éligibilité au bfcache.
  3. Vérifiez le LCP prerender. S'il est supérieur à 200 ms, le pipeline de prerender ne donne pas de résultats. Vérifiez que votre JSON Speculation Rules est valide, vérifiez que les pages cibles ne renvoient aucune logique de blocage et confirmez que les activations sont comptabilisées dans Chrome DevTools sous Speculation Rules.

Règle empirique d'ingénierie

  • navigate : Doit atteindre votre seuil LCP grâce à une optimisation normale : TTFB rapide, fetchpriority="high" sur l'image LCP, aucune ressource bloquant le rendu.
  • back_forward : Devrait être 10 à 20 fois plus rapide que navigate. Sinon, le bfcache est défaillant.
  • prerender : Devrait afficher un LCP inférieur à 200 ms. Sinon, vos Speculation Rules sont mal configurées.
  • reload : Le TTFB ne devrait pas être considérablement pire que navigate. Si c'est le cas, corrigez vos en-têtes de revalidation de cache.

Le Navigation Type est la dimension qui sépare « comment ma page se comporte-t-elle ? » de « comment ma page se comporte-t-elle selon chaque stratégie de chargement du navigateur ? ». Cette distinction est la différence entre deviner et déboguer.