Core/Dash Forstå dashboardene for metrikknedbrytning

Forstå dashboardet for metrikknedbrytning

Sammensatte metrikker som LCP og INP aggregerer flere ulike tidshendelser. Å optimalisere den totale poengsummen krever at du isolerer disse underliggende komponentene. Dashboardet for metrikknedbrytning dissekerer ytelse i granulære faser for å identifisere den spesifikke flaskehalsen.

Dette verktøyet erstatter bred optimalisering med presise tekniske mål. Det tilskriver latens til serveren, nettverket eller klientkjøringen.

Anatomien til nedbrytningsdashboardet

Dashboardet gir tre synkroniserte visninger for å isolere rotårsaken til latens:

• Bidragsdonut: Visualiserer den relative vekten til hver underdel. Den svarer på spørsmålet «Hva er den største faktoren?» Hvis `Time to First Byte` tar opp 70 % av diagrammet, vet du at problemet er backend-relatert.
• Historisk tidslinje: Viser trender for de absolutte verdiene til hver komponent over tid. Bruk denne til å korrelere endringer i ytelse med spesifikke hendelser som deployer.
• Segmentert datatabell: Bryter ned metrikken etter dimensjon (URL, enhet osv.). Hver rad inneholder en fordelingssøyle som viser den unike profilen til segmentet, slik at du kan oppdage avvik.

LCP-komponenter (Largest Contentful Paint)

LCP måler lasteytelse. Vi deler denne metrikken inn i fire faser:

• TTFB (Time to First Byte): Serverens responstid. Høy TTFB indikerer trege databaseforespørsler eller mangel på edge-caching.
• Lasteforsinkelse: Gapet mellom den første HTML-responsen og starten på nedlastingen av LCP-ressursen. Dette måler oppdagelseslatens for ressursen.
• Lastetid: Tiden det tar å laste ned LCP-ressursen (bilde eller font) over nettverket. Dette korrelerer med filstørrelse og båndbredde.
• Renderingsforsinkelse: Tiden mellom ressursen er ferdig nedlastet og til den tegnes på skjermen. Høy renderingsforsinkelse indikerer ofte at main thread blokkeres av JavaScript.

TTFB-komponenter (Time to First Byte)

TTFB fungerer som en indikator på serverens responstid. Denne nedbrytningen isolerer nettverkstilkoblingens faser:

• Venting: Tiden nettleseren bruker på å vente på at serveren skal generere et svar (backend-prosessering).
• Cache: Tid brukt på å sjekke lokale eller mellomliggende cacher.
• DNS: Varigheten av DNS-oppslaget.
• Tilkobling: Tiden det tar å etablere TCP-tilkoblingen.
• Forespørsel: Tiden det tar å sende HTTP-forespørselshoder.

INP-komponenter (Interaction to Next Paint)

INP måler interaktivitet. Vi segmenterer interaksjonens livssyklus for å identifisere blokkering av main thread:

• Inndataforsinkelse: Tiden mellom brukerinteraksjon og kjøring av hendelseshåndterer. Høy inndataforsinkelse betyr at main thread var opptatt.
• Prosessering: Tiden det tar å kjøre event-callbacks. Dette representerer effektiviteten til din JavaScript-logikk.
• Presentasjon: Tiden det tar for nettleseren å beregne layout og tegne neste ramme.

Arbeidsflyt for diagnostisering

Følg denne sekvensen for å diagnostisere en regresjon:

• Kvantifiser flaskehalsen: Se på donut-diagrammet for å finne den dominerende underdelen. Hvis `TTFB` er høy, sjekk serveren din. Hvis `Resource Load Delay` er høy, sjekk ressursprioriteringen din.
• Fastslå årsakssammenheng: Sjekk tidslinjen for å korrelere toppen med en spesifikk produksjonssetting eller innholdsoppdatering.
• Isoler konteksten: Bruk datatabellen for å se om dette mønsteret gjelder for alle sider, eller om det er spesifikt for en bestemt mal. Å finne mønsteret er nøkkelen til å rulle ut en skalerbar løsning.

Optimalisering av Core Web Vitals

Bruk disse nedbrytningene til å sende saker til riktig utviklerteam. Tildel TTFB-problemer til backend. Tildel lasteforsinkelse og renderingsforsinkelse til frontend. Tildel DNS- og tilkoblingslatens til infrastruktur. Denne strømlinjeformede triage-prosessen reduserer feilsøkingstiden og fremskynder løsningen.