Core/Dash Forstå Metric Breakdown-dashbordene

Forstå Metric Breakdown-dashbordet

Sammensatte metrikker som LCP og INP aggregerer flere distinkte tidshendelser. Optimalisering av totalscoren krever isolering av disse underliggende komponentene. Metric Breakdown-dashbordet dissekerer ytelse i granulære faser for å identifisere den spesifikke flaskehalsen.

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

Anatomien til Breakdown-dashbordet

Dashbordet gir tre synkroniserte visninger for å isolere rotårsaken til forsinkelse:

• Contribution Donut: Visualiserer den relative vekten av hver underdel. Det svarer på spørsmålet "Hva er den største faktoren?" Hvis `Time to First Byte` opptar 70 % av diagrammet, vet du at problemet er backend-relatert.
• Historisk tidslinje: Viser trendene for de absolutte verdiene til hver komponent over tid. Bruk dette til å korrelere ytelsesendringer med spesifikke hendelser som utrullinger.
• Segmentert datatabell: Bryter ned metrikken etter dimensjon (URL, enhet, osv.). Hver rad inkluderer en distribusjonslinje som avslører den unike profilen til det segmentet, og hjelper deg med å oppdage avvik.

LCP-komponenter (Largest Contentful Paint)

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

• TTFB (Time to First Byte): Serverens responstid. Høy TTFB indikerer trege databasespørringer eller mangel på edge-caching.
• Load Delay: Gapet mellom den første HTML-responsen og starten på nedlastingen av LCP-ressursen. Dette måler forsinkelse i ressursoppdagelse.
• Load Time: Varigheten som kreves for å laste ned LCP-ressursen (bilde eller font) over nettverket. Dette korrelerer med filstørrelse og båndbredde.
• Render Delay: Tiden mellom ressursen er ferdig nedlastet og opptegning på skjermen. Høy Render Delay indikerer ofte blokkering av hovedtråden forårsaket av JavaScript.

TTFB-komponenter (Time to First Byte)

TTFB fungerer som en proxy for serverresponsivitet. Denne nedbrytingen isolerer faser i nettverkstilkoblingen:

• Waiting: Tiden nettleseren bruker på å vente på at serveren skal generere en respons (Backend-behandling).
• Cache: Tid brukt på å sjekke lokale eller mellomliggende cacher.
• DNS: Varigheten av Domain Name System-oppslaget.
• Connection: Tid brukt på å etablere TCP-tilkoblingen.
• Request: Tid brukt på å sende HTTP-forespørselsheaderne.

INP-komponenter (Interaction to Next Paint)

INP måler interaktivitet. Vi segmenterer interaksjonslivssyklusen for å finne blokkering av hovedtråden:

• Input Delay: Tiden mellom brukerinteraksjon og utførelse av hendelseshåndterer. Høy Input Delay betyr at hovedtråden var opptatt.
• Processing: Tiden det tar å utføre hendelses-callbacks. Dette representerer effektiviteten til din JavaScript-logikk.
• Presentation: Tiden det tar for nettleseren å beregne layout og tegne neste ramme (paint).

Diagnostisk arbeidsflyt

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.
• Etabler årsakssammenheng: Sjekk tidslinjen for å korrelere toppen med en spesifikk utrulling 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 å distribuere en skalerbar fiks.

Optimalisering av Core Web Vitals

Bruk disse nedbrytingene til å rute saker til riktig ingeniørteam. Tildel TTFB-problemer til Backend. Tildel Load Delay og Render Delay til Frontend. Tildel DNS/Connection-forsinkelse til Infrastruktur. Denne strømlinjeformede triage-prosessen reduserer undersøkelsestiden og akselererer løsningen.