CoreDash Dimension: Top level Pathname

Dimension: Top level Pathname (ff)

Einzelne URLs liefern spezifische Daten. Top level Pathname aggregiert diesen Traffic nach dem ersten Verzeichnis im URL-Pfad. Diese automatische Gruppierung ermöglicht es Ihnen, die Performance gesamter Geschäftsbereiche und Templates in einer einzigen Ansicht zu prüfen.

Der Zweck der Pathname-Analyse

Performance-Engpässe liegen oft in der Codestruktur begründet und nicht im spezifischen Content. Der Top level Pathname bildet die Routing-Struktur Ihrer Anwendung direkt ab..

• Template-Isolierung: Die Gruppierung nach Katalog- oder Inventarabschnitten aggregiert die Performance für jeden Artikel in Ihrer Datenbank. Wenn dieser gesamte Pfad langsam ist, haben Sie einen Fehler im Template der Produktseite identifiziert und nicht nur ein einzelnes fehlerhaftes Bild.
• Architektur-Vergleich: Vergleichen Sie Ihre CMS-gesteuerten Content-Routen mit Ihren dynamischen E-Commerce-Routen. Eine signifikante Abweichung beim TTFB zwischen diesen Abschnitten deutet darauf hin, dass ein Stack weniger performant ist als der andere.
• Feature-Auditing: Checkout-Funnel und Warenkorbseiten laden oft schwere Drittanbieter-Skripte, die auf anderen Seiten nicht vorkommen. Diese Ansicht isoliert diesen Effekt, sodass Sie die Kosten dieser Integrationen präzise messen können.

Metrik-spezifische Szenarien

Nutzen Sie die Pathname-Gruppierung, um spezifische Arten von Regressionen zu diagnostizieren.

1. LCP (Largest Contentful Paint): Ein hoher LCP auf medienreichen Katalogseiten deutet oft auf einen langsamen API-Aufruf hin, der das Hauptproduktbild verzögert. Umgekehrt weist ein hoher LCP auf textlastigen Blog-Routen meist auf nicht optimierte Hero-Images im Artikel-Template hin.
2. CLS (Cumulative Layout Shift): Wenn Long-Form-Content-Seiten einen schlechten CLS-Score aufweisen, prüfen Sie auf Anzeigen oder dynamische Elemente, die in den Content-Body injiziert werden. Wenn Transaktionsschritte sich verschieben, suchen Sie nach spät ladenden Versandrechnern oder Trust-Badges.
3. INP (Interaction to Next Paint): Ein hoher INP bei Suchoberflächen deutet darauf hin, dass Ihre Filter- oder Suchlogik den Main Thread blockiert. Dies signalisiert die Notwendigkeit, komplexe JavaScript-Interaktionen zu optimieren.
4. TTFB (Time to First Byte): Eine Disparität beim TTFB zwischen authentifizierten Benutzerbereichen und statischen Landingpages verdeutlicht die Kosten des Server-Side-Renderings für angemeldete Benutzer im Vergleich zu gecachten öffentlichen Seiten.

Verbesserung der Core Web Vitals

Nutzen Sie den Top level Pathname, um Ihre Engineering-Ressourcen gezielt einzusetzen.

• Den langsamen Pfad identifizieren: Sortieren Sie die Tabelle nach Impact. Lokalisieren Sie das Verzeichnis (z. B. /blog/) mit dem höchsten Aufkommen an schlechter Performance.
• Bestandteile untersuchen: Klicken Sie auf den Pfad, um das Dashboard zu filtern. Wechseln Sie zur URL-Dimension, um die einzelnen Seiten zu sehen, die diese Gruppe bilden.
• Die Ursache unterscheiden: Analysieren Sie die Verteilung langsamer URLs innerhalb des Pfades:

Systemischer Fehler: Wenn der Großteil der URLs im Pfad langsam ist, liegt das Problem im gemeinsamen Template-Code oder in der Backend-Logik. Korrigieren Sie das Template, um die gesamte Gruppe zu optimieren.

Spezifische Ausreißer: Wenn nur wenige trafficstarke URLs langsam sind, verfälschen spezifische Content-Assets (wie ein schweres Video oder eine nicht optimierte Bildergalerie) den aggregierten p75. Optimieren Sie diese spezifischen Seiten, um die Gesundheit des Pfades wiederherzustellen.