Dimension Core/Dash : Chemin d'accès de premier niveau

Dimension : Chemin d'accès de premier niveau (ff)

Les URL individuelles fournissent des données spécifiques. Le chemin d'accès de premier niveau agrège ce trafic selon le premier répertoire du chemin de l'URL. Ce regroupement automatique vous permet d'auditer la performance d'unités commerciales entières et de templates en une seule vue.

L'objectif de l'analyse par chemin d'accès

Les goulots d'étranglement de performance résident souvent dans la structure du code plutôt que dans le contenu spécifique. Le chemin d'accès de premier niveau correspond directement à la structure de routage de votre application.

• Isolation des templates : Le regroupement par sections de catalogue ou d'inventaire agrège la performance pour chaque article de votre base de données. Si ce chemin entier est lent, vous avez identifié un défaut dans le template de la page produit plutôt qu'une seule mauvaise image.
• Comparaison d'architecture : Comparez vos routes de contenu gérées par CMS avec vos routes e-commerce dynamiques. Une variance significative du TTFB entre ces sections suggère qu'une stack est moins performante que l'autre.
• Audit des fonctionnalités : Les tunnels de commande et les pages panier chargent souvent des scripts tiers lourds que les autres pages ne chargent pas. Cette vue isole cet impact afin que vous puissiez mesurer le coût de ces intégrations.

Scénarios spécifiques aux métriques

Utilisez le regroupement par chemin d'accès pour diagnostiquer des types spécifiques de régression.

1. LCP (Largest Contentful Paint) : Un LCP élevé sur des pages de catalogue riches en médias indique souvent un appel API lent retardant l'image produit principale. Inversement, un LCP élevé sur des routes de blog riches en texte indique généralement des images hero non optimisées dans le template de l'article.
2. CLS (Cumulative Layout Shift) : Si les pages de contenu long format ont un mauvais score CLS, vérifiez les publicités ou les éléments dynamiques injectés dans le corps du contenu. Si les étapes transactionnelles subissent des décalages, cherchez des calculateurs d'expédition ou des badges de confiance à chargement tardif.
3. INP (Interaction to Next Paint) : Un INP élevé sur les interfaces de recherche indique que votre logique de filtrage ou de recherche bloque le thread principal. Cela identifie un besoin d'optimiser l'interactivité JavaScript complexe.
4. TTFB (Time to First Byte) : Une disparité de TTFB entre les zones utilisateurs authentifiés et les landing pages statiques met en évidence le coût du rendu côté serveur pour les utilisateurs connectés par rapport aux pages publiques mises en cache.

Améliorer les Core Web Vitals

Utilisez le chemin d'accès de premier niveau pour orienter vos ressources d'ingénierie.

• Identifiez le chemin lent : Triez le tableau par Impact. Localisez le répertoire (ex : /blog/) ayant le volume le plus élevé de mauvaises performances.
• Inspectez les constituants : Cliquez sur le chemin pour filtrer le tableau de bord. Basculez vers la dimension URL pour voir les pages individuelles composant ce groupe.
• Distinguez la cause : Analysez la distribution des URL lentes au sein du chemin :

Défaillance systémique : Si la majorité des URL du chemin sont lentes, le problème réside dans le code partagé du template ou la logique backend. Corrigez le template pour résoudre le problème du groupe entier.

Valeurs aberrantes spécifiques : Si seules quelques URL à fort trafic sont lentes, des assets de contenu spécifiques (comme une vidéo lourde ou une galerie d'images non optimisée) faussent le p75 agrégé. Optimisez ces pages spécifiques pour rétablir la santé du chemin.