Core/Dash-dimensjon: Toppnivå-sti

Dimensjon: Toppnivå-sti (ff)

Individuelle URL-er gir spesifikk data. Toppnivå-sti aggregerer denne trafikken etter den første katalogen i URL-stien. Denne automatiske grupperingen lar deg revidere ytelsen til hele forretningsenheter og maler i én enkelt visning.

Formålet med stianalyse

Ytelsesflaskehalser eksisterer ofte i kodestrukturen fremfor spesifikt innhold. Toppnivå-stien kartlegges direkte til applikasjonens rutestruktur.

• Malisolasjon: Gruppering etter katalog- eller varelagerseksjoner aggregerer ytelsen for hver enhet i databasen din. Hvis hele denne stien er treg, har du identifisert en feil i produktsidemalen fremfor et enkelt, dårlig optimalisert bilde.
• Arkitektursammenligning: Sammenlign dine CMS-drevne innholdsruter med dine dynamiske e-handelsruter. Betydelig varians i TTFB mellom disse seksjonene antyder at den ene stacken har dårligere ytelse enn den andre.
• Funksjonsrevisjon: Kassetrakter og handlekurvsider laster ofte tunge tredjepartsskript som andre sider ikke gjør. Denne visningen isolerer den påvirkningen slik at du kan måle kostnaden av disse integrasjonene.

Metrikkspesifikke scenarier

Bruk stigruppering for å diagnostisere spesifikke typer regresjon.

1. LCP (Largest Contentful Paint): Høy LCP på medietunge katalogsider peker ofte mot et tregt API-kall som forsinker hovedproduktbildet. Motsatt vil høy LCP på teksttunge bloggruter vanligvis indikere uoptimaliserte hero-bilder i artikkelmalen.
2. CLS (Cumulative Layout Shift): Hvis lange innholdssider har en dårlig CLS-score, sjekk for annonser eller dynamiske elementer som injiseres i innholdskroppen. Hvis transaksjonelle steg forskyver seg, se etter sent innlastende fraktkalkulatorer eller tillitsmerker.
3. INP (Interaction to Next Paint): En høy INP på søkegrensesnitt indikerer at filtrerings- eller søkelogikken din blokkerer hovedtråden. Dette identifiserer et behov for å optimalisere kompleks JavaScript-interaktivitet.
4. TTFB (Time to First Byte): En forskjell i TTFB mellom autentiserte brukerområder og statiske landingssider fremhever kostnaden ved server-side rendering for innloggede brukere kontra bufrede offentlige sider.

Forbedring av Core Web Vitals

Bruk toppnivå-stien for å styre ingeniørressursene dine.

• Identifiser den trege stien: Sorter tabellen etter innvirkning (Impact). Finn katalogen (f.eks. /blog/) med høyest volum av dårlig ytelse.
• Inspiser bestanddelene: Klikk på stien for å filtrere dashbordet. Bytt til URL-dimensjonen for å se de individuelle sidene som utgjør den gruppen.
• Kartlegg årsaken: Analyser fordelingen av trege URL-er innenfor stien:

Systemisk feil: Hvis majoriteten av URL-ene i stien er trege, ligger problemet i den delte malkoden eller backend-logikken. Løs malen for å fikse hele gruppen.

Spesifikke uteliggere: Hvis bare noen få URL-er med høy trafikk er trege, skjevfordeler spesifikke innholdsressurser (som en tung video eller et uoptimalisert bildegalleri) den aggregerte p75-verdien. Optimaliser disse spesifikke sidene for å gjenopprette stiens helse.