Core/Dash-dimensjon: LOAF

Finn de nøyaktige skript-URL-ene som blokkerer main thread-en din og forverrer INP ved å attribuere Long Animation Frames til kilden deres.

Gratis prøveperiode

Trusted by market leaders · Client results

loopearplugsmy work featured on web.devfotocasavpnwhowhatwearnina caresnvsaturnerasmusmcharvardhappyhorizonadevintadpg mediamonarchaleteiacompareworkivamarktplaatsnestlekpnperionebay

Dimensjon: Long Animation Frames (lurl)

LOAF-dimensjonen viser 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-bundle, en tredjeparts-analysetag, en chat-widget, en samtykkeløsning eller hva som helst annet som kjørte lenge nok til å blokkere rendering. Dette er attribusjon på kildenivå, ikke bare en 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 URL-ene deres var. Det er denne forskjellen som gjør dimensjonen nyttig i produksjon.

Hvorfor Long Tasks ikke var nok

Long Tasks API (tilgjengelig siden 2017) flagget alle main thread-oppgaver som overskred 50 ms, men det ga deg nesten ingen attribusjon. Du kunne se at blokkering skjedde, men du kunne ikke se hva som forårsaket det. Utviklere brukte timer på å korrelere tidsstempler for oppgaver med network waterfalls for å gjette hvilket skript som var ansvarlig.

LoAF API-et endrer på dette. Det rapporterer PerformanceLongAnimationFrameEntry-objekter, som hver inneholder en scripts-array. Hvert element 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 lang frame, og lagrer det som verdi for LOAF-dimensjonen. Resultatet er en rangert liste over skript-URL-er sortert etter hvor ofte de dukker opp i brukernes lange framer.

Hvordan CoreDash bruker LoAF-data

Hver gang en brukerinteraksjon utløser en lang animasjons-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 antallet økter der det aktuelle skriptet forårsaket en lang 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 samtykkeløsning)
  • 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 data fra CoreDash står tredjepartsskript for lange animasjons-framer på rundt 60–70 % av nettstedene. Tag-managere alene bidrar til lange framer på omtrent 45 % av de overvåkede nettstedene. Førsteparts-bundler dominerer resten, vanligvis på grunn av React-re-renders eller uoptimerte event-handlere.

INP-attribusjon via LoAF

INP måler tiden fra brukerinteraksjon til neste frame-paint. Hvis dette gapet overskrider 200 ms, klassifiserer Google opplevelsen som «trenger forbedring». LoAF-dataene forteller deg hvilket skript som kjørte i løpet av dette gapet. En INP på 280 ms der 210 ms skyldes et skript for en samtykkeløsning, er et helt annet problem enn en INP på 280 ms der 190 ms skyldes din egen checkout-handler. Løsningen er ulik. Teamet som er ansvarlig, er ulikt. Hvor mye det haster, er ulikt.

Uten LoAF-attribusjon ser begge identiske ut i INP-histogrammet ditt. Med den kan du sende problemet videre til riktig person umiddelbart.

Arbeidsflyt for feilsøking

  1. Åpne LOAF-dimensjonen i CoreDash: Sorter etter frekvens (hvor mange økter som hadde denne URL-en i en lang frame). Den øverste oppføringen er ditt viktigste mål.
  2. Kryssfiltrer med INP: Bruk LOAF-filteret på INP-metrikkvisningen din. Sjekk om INP p75 endrer seg når du isolerer økter der det skriptet kjørte. En økning på 30+ ms bekrefter at skriptet bidrar til INP-forverring i produksjon.
  3. Klassifiser som førstepart eller tredjepart: Ditt eget domene i URL-en betyr at du kontrollerer løsningen. En tredjeparts CDN-URL betyr at du enten må fjerne, utsette eller erstatte leverandørskriptet.
  4. Implementer løsningen og verifiser: For tredjepartsskript kan du utsette lasting til etter den første brukerinteraksjonen ved å bruke en fasade eller forsinket init. For førstepartskode bør du profilere den spesifikke funksjonen i Chrome DevTools med CPU-throttling satt til 4x. Rull ut endringen og se LOAF-dimensjonen oppdatere seg i løpet av 24–48 timer med reell brukertrafikk.

Tekniske tommelfingerregler

  • Enhver enkelt skript-URL som dukker opp i lange framer i mer enn 5 % av øktene, er verdt å undersøke. Med den frekvensen påvirker det en målbart stor andel av reelle brukere i løpet av måneden.
  • Tredjepartsskript bør ikke kjøre under interaksjonshåndterere. Hvis en tag manager trigges synkront på en klikk-event, er det et konfigurasjonsproblem, ikke en begrensning i nettleseren.
  • En lang frame-varighet på over 200 ms for et enkelt skript er et tydelig signal. LoAF API-et rapporterer varighet per skript inni framen. Ethvert skript som bruker 200 ms eller mer av en frame, er hovedårsaken til den påfølgende INP-en.
  • Førstepartsskript i LOAF-listen peker ofte på rammeverk-overhead. React, Vue og Angular kan alle produsere lange framer under tilstandsoppdateringer. LOAF-URL-en vil være din egen bundle. Profiler komponenttreet, ikke bare nettverket.

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