Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

LOAF-dimensionen fremhæver URL'erne på scripts, der forårsagede Long Animation Frames i løbet af dine brugeres sessioner. Hver værdi er en script-URL: en førsteparts-bundle, et tredjeparts-analytics-tag, en chat-widget, en consent manager eller hvad der ellers kørte længe nok til at blokere rendering. Dette er attribuering på kildeniveau, ikke bare en stack trace, du skal rekonstruere i DevTools.

CoreDash indsamler disse data ved hjælp af Long Animation Frames API (LoAF), som Chrome leverer som en erstatning for det ældre Long Tasks API. Hvor Long Tasks fortalte dig, at en frame tog for lang tid, fortæller LoAF dig, hvilke scripts der kørte i den pågældende frame, og hvad deres URL'er var. Det er den forskel, der gør denne dimension nyttig i produktion.

Hvorfor Long Tasks ikke var nok

Long Tasks API'et (tilgængeligt siden 2017) markerede enhver main thread-task, der oversteg 50ms, men det gav dig næsten ingen attribuering. Du kunne se, at der skete en blokering; du kunne ikke se, hvad der forårsagede den. Udviklere brugte timer på at korrelere task-tidsstempler med netværks-waterfalls i et forsøg på at gætte, hvilket script der bar ansvaret.

LoAF API'et ændrer dette. Det rapporterer PerformanceLongAnimationFrameEntry-objekter, der hver indeholder et scripts-array. Hver post i det array har en invokerType, en sourceURL og en duration. CoreDash læser sourceURL for hvert script, der kørte i løbet af en lang frame, og gemmer det som LOAF-dimensionsværdien. Resultatet er en rangeret liste over script-URL'er sorteret efter, hvor ofte de optræder i dine brugeres lange frames.

Hvordan CoreDash bruger LoAF-data

Hver gang en brugerinteraktion udløser en lang animation frame, registrerer CoreDash de medvirkende script-URL'er sammen med INP-observationen. Det betyder, at du kan filtrere dine INP-data efter LOAF-URL og se, hvilket script der er ansvarligt for dine værste interaktioner. Dimensionen grupperer efter URL, så du ser en optælling af, hvor mange sessioner der involverede det pågældende script i at forårsage en lang frame.

Typiske poster, du vil se i LOAF-dimensionen:

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

I CoreDash-data står tredjeparts-scripts for lange animation frames på omkring 60-70 % af alle sites. Tag managers alene bidrager til lange frames på cirka 45 % af overvågede domæner. Førsteparts-bundles dominerer resten, oftest på grund af React re-renders eller uoptimerede event handlers.

INP-attribuering via LoAF

INP måler tiden fra brugerinteraktion til næste frame paint. Hvis det tidsrum overstiger 200ms, klassificerer Google oplevelsen som "trænger til forbedring". LoAF-dataene fortæller dig, hvilket script der kørte i det tidsrum. En 280ms INP, hvor 210ms kan spores til et consent manager-script, er et helt andet problem end en 280ms INP, hvor 190ms kan spores til din egen checkout-handler. Løsningen er en anden. Det ansvarlige team er et andet. Vigtigheden er en anden.

Uden LoAF-attribuering ser begge identiske ud i dit INP-histogram. Med den kan du sende problemet videre til den rigtige person med det samme.

Debugging Workflow

1. Åbn LOAF-dimensionen i CoreDash: Sortér efter frekvens (hvor mange sessioner der så denne URL i en lang frame). Den øverste post er dit højest prioriterede mål.
2. Krydsfiltrer med INP: Anvend LOAF-filtret på din INP-metrikvisning. Tjek om INP p75 ændrer sig, når du isolerer sessioner, hvor det pågældende script kørte. En stigning på 30ms+ bekræfter, at scriptet bidrager til INP-forringelse i produktion.
3. Klassificer som førsteparts eller tredjeparts: Dit eget domæne i URL'en betyder, at du kontrollerer løsningen. En tredjeparts-CDN-URL betyder, at du enten skal fjerne, forsinke eller udskifte leverandørscriptet.
4. Anvend løsningen og bekræft: For tredjeparts-scripts, udskyd indlæsningen (defer) indtil efter den første brugerinteraktion ved hjælp af en facade eller forsinket init. For førstepartskode, profilér den specifikke funktion i Chrome DevTools med CPU-throttling sat til 4x. Udrul ændringen og se LOAF-dimensionen opdatere sig inden for 24-48 timer med reel brugertrafik.

Tommelfingerregel for udviklere

• Enhver enkelt script-URL, der optræder i lange frames for mere end 5 % af sessionerne, er værd at undersøge. Ved den frekvens påvirker det en målbar andel af reelle brugere i løbet af måneden.
• Tredjeparts-scripts bør ikke køre i interaction handlers. Hvis en tag manager affyres synkront på en klik-event, er det et konfigurationsproblem, ikke en browserbegrænsning.
• En varighed på over 200ms for en lang frame for et enkelt script er et klart signal. LoAF API'et rapporterer varighed pr. script inde i framen. Ethvert script, der forbruger 200ms eller mere af en frame, er den primære årsag til den INP, der følger.
• Førsteparts-scripts på LOAF-listen peger ofte på framework-overhead. React, Vue og Angular kan alle producere lange frames under state updates. LoAF-URL'en vil være din egen bundle. Profilér komponenttræet, ikke kun netværket.

LOAF-dimensionen giver dig noget, som ingen syntetisk test kan: bevis på, hvilke scripts der blokerer reelle brugere i produktion, rangeret efter virkelighedens frekvens. Filtrer efter den, krydsreferér med dine INP-data, og du har en prioriteret liste over præcis, hvad der skal rettes, og i hvilken rækkefølge.