Core/Dash-dimensjon: LOAF

Dimensjon: Long Animation Frames (lurl)

LOAF-dimensjonen synliggjør URL-ene til skript som forårsaket Long Animation Frames i løpet av brukernes økter. Hver verdi er en skript-URL: en førsteparts pakke, en tredjeparts analysekode, en chat-widget, en samtykkehåndterer, eller hva som helst annet som kjørte lenge nok til å blokkere rendringen. Dette er attribusjon på kildenivå, ikke bare et stack trace du må rekonstruere i DevTools.

CoreDash samler inn disse dataene ved hjelp av Long Animation Frames API (LoAF), som Chrome leverer som en erstatning for det eldre Long Tasks API. Der Long Tasks fortalte deg at en frame tok for lang tid, forteller LoAF deg hvilke skript som kjørte i den framen og hva deres URL-er var. Det er denne forskjellen som gjør denne dimensjonen nyttig i produksjon.

Hvorfor Long Tasks ikke var nok

Long Tasks API (tilgjengelig siden 2017) flagget enhver hovedtråd-oppgave som oversteg 50ms, men det ga deg nesten ingen attribusjon. Du kunne se at blokkering skjedde; du kunne ikke se hva som forårsaket det. Utviklere brukte timevis på å korrelere oppgavetidsstempler med nettverksfossefall, for å gjette hvilket skript som var ansvarlig.

LoAF API endrer dette. Det rapporterer PerformanceLongAnimationFrameEntry-objekter, som hver inneholder en scripts-array. Hver oppføring i den arrayen har en invokerType, en sourceURL og en duration. CoreDash leser sourceURL for hvert skript som kjørte i løpet av en long frame, og lagrer det som LOAF-dimensjonens verdi. Resultatet er en rangert liste over skript-URL-er sortert etter hvor ofte de dukker opp i brukernes long frames.

Hvordan CoreDash bruker LoAF-data

Hver gang en brukerinteraksjon utløser en long animation frame, registrerer CoreDash de medvirkende skript-URL-ene sammen med INP-observasjonen. Dette betyr at du kan filtrere INP-dataene dine etter LOAF-URL og se hvilket skript som er ansvarlig for dine verste interaksjoner. Dimensjonen grupperer etter URL, slik at du ser en telling av hvor mange økter som involverte det skriptet i å forårsake en long frame.

Typiske oppføringer du vil se i LOAF-dimensjonen:

• https://www.googletagmanager.com/gtm.js (Google Tag Manager-container)
• https://cdn.cookielaw.org/consent/... (OneTrust eller lignende samtykkeplattform)
• https://js.intercomcdn.com/... (chat-widget)
• /static/js/app.bundle.js (din egen applikasjonskode)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

I CoreDash-data står tredjepartsskript for long animation frames på omtrent 60-70 % av nettstedene. Tag managere alene bidrar til long frames på omtrent 45 % av overvåkede domener. Førstepartspakker dominerer resten, vanligvis på grunn av React re-renders eller uoptimaliserte hendelseshåndterere.

INP-attribusjon via LoAF

INP måler tiden fra brukerinteraksjon til neste frame paint. Hvis det gapet overstiger 200ms, klassifiserer Google opplevelsen som "trenger forbedring". LoAF-dataene forteller deg hvilket skript som kjørte i løpet av det gapet. En INP på 280ms der 210ms kan spores til et samtykkeskript er et helt annet problem enn en INP på 280ms der 190ms kan spores til din egen utsjekkshåndterer. Løsningen er annerledes. Teamet som er ansvarlig er annerledes. Hastegraden er annerledes.

Uten LoAF-attribusjon ser begge identiske ut i ditt INP-histogram. Med det, kan du rute problemet til riktig person umiddelbart.

Arbeidsflyt for feilsøking

1. Åpne LOAF-dimensjonen i CoreDash: Sorter etter frekvens (hvor mange økter som så denne URL-en i en long frame). Oppføringen på toppen er ditt høyest prioriterte mål.
2. Kryssfiltrer med INP: Bruk LOAF-filteret på din INP-metrikkvisning. Sjekk om INP p75 endres når du isolerer økter der det skriptet kjørte. En økning på 30ms+ bekrefter at skriptet bidrar til INP-forverring i produksjon.
3. Klassifiser som førsteparts eller tredjeparts: Ditt eget domene i URL-en betyr at du kontrollerer løsningen. En tredjeparts CDN-URL betyr at du enten må fjerne, forsinke, eller erstatte leverandørskriptet.
4. Bruk løsningen og bekreft: For tredjepartsskript, utsett (defer) innlasting til etter den første brukerinteraksjonen ved bruk av en fasade eller forsinket init. For førstepartskode, profiler den spesifikke funksjonen i Chrome DevTools med CPU-throttling satt til 4x. Rull ut endringen og se LOAF-dimensjonen oppdatere seg innen 24-48 timer med reell brukertrafikk.

Tommelfingerregel for utviklere

• Enhver enkelt skript-URL som dukker opp i long frames i mer enn 5 % av øktene er verdt å undersøke. Ved den frekvensen påvirker det en målbar andel av ekte brukere i løpet av måneden.
• Tredjepartsskript bør ikke kjøre i løpet av interaksjonshåndterere. Hvis en tag manager utløses synkront på en klikkhendelse, er det et konfigurasjonsproblem, ikke en nettleserbegrensning.
• En long frame-varighet på over 200ms for et enkelt skript er et tydelig signal. LoAF API rapporterer varighet per skript i framen. Ethvert skript som forbruker 200ms eller mer av en frame er hovedårsaken til den etterfølgende INP-en.
• Førstepartsskript i LOAF-listen peker ofte på rammeverk-overhead. React, Vue og Angular kan alle produsere long frames under tilstandsoppdateringer. LoAF-URL-en vil være din egen pakke. Profiler komponent-treet, ikke bare nettverket.

LOAF-dimensjonen gir deg noe som ingen syntetisk test kan: bevis på hvilke skript som blokkerer ekte brukere i produksjon, rangert etter frekvens i den virkelige verden. Filtrer etter den, kryssreferer med INP-dataene dine, og du har en prioritert liste over nøyaktig hva som skal fikses og i hvilken rekkefølge.