Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

LOAF-dimensionen synliggør URL'erne for de scripts, der forårsagede Long Animation Frames i løbet af dine brugeres sessioner. Hver værdi er en script-URL: et førsteparts-bundle, et tredjeparts analyse-tag, en chat-widget, en samtykkehåndtering, eller hvad der ellers kørte længe nok til at blokere for renderingen. Dette er tilskrivning på kildeniveau, ikke bare en staksporing, 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 inde i den 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 hovedtrådsopgave, der overskred 50ms, men det gav dig næsten ingen tilskrivning. Du kunne se, at blokeringen fandt sted; du kunne ikke se, hvad der forårsagede den. Udviklere brugte timer på at korrelere opgavetidsstempler med netværksvandfald, og gættede på, hvilket script der var ansvarligt.

LoAF API'et ændrer dette. Det rapporterer PerformanceLongAnimationFrameEntry-objekter, der hver især 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 long frame, og gemmer den som LOAF-dimensionsværdien. Resultatet er en rangeret liste over script-URL'er, sorteret efter hvor ofte de optræder i dine brugeres long frames.

Hvordan CoreDash bruger LoAF-data

Hver gang en brugerinteraktion udløser en long animation frame, registrerer CoreDash de medvirkende script-URL'er sammen med INP-observation. 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 long 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 samtykkeplatform)
• 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 tegner tredjeparts-scripts sig for long animation frames på omkring 60-70 % af alle websites. Tag managers alene bidrager til long frames på cirka 45 % af de overvågede ejendomme. Førsteparts-bundles dominerer resten, normalt på grund af React re-renders eller uoptimerede hændelseshåndteringer.

INP-tilskrivning via LoAF

INP måler tiden fra brugerinteraktion til næste frame paint. Hvis den kløft overstiger 200ms, klassificerer Google oplevelsen som "needs improvement" (kræver forbedring). LoAF-dataene fortæller dig, hvilket script der kørte i løbet af den kløft. En 280ms INP, hvor 210ms spores til et samtykke-script, er et helt andet problem end en 280ms INP, hvor 190ms spores til din egen checkout-handler. Løsningen er forskellig. Det ansvarlige team er forskelligt. Vigtigheden er forskellig.

Uden LoAF-tilskrivning ser begge identiske ud i dit INP-histogram. Med det kan du straks dirigere problemet videre til den rigtige person.

Debugging-workflow

1. Åbn LOAF-dimensionen i CoreDash: Sorter efter hyppighed (hvor mange sessioner, der så denne URL i en long 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 ændres, når du isolerer sessioner, hvor det script kørte. En stigning på 30ms+ bekræfter, at scriptet bidrager til INP-forringelse i produktion.
3. Klassificer som førstepart eller tredjepart: Dit eget domæne i URL'en betyder, at du kontrollerer rettelsen. En tredjeparts CDN URL betyder, at du enten skal fjerne, forsinke eller udskifte leverandørens script.
4. Anvend rettelsen og verificer: For tredjeparts-scripts skal du udskyde indlæsningen indtil efter den første brugerinteraktion ved hjælp af en facade eller en forsinket initiering. For førstepartskode skal du profilere den specifikke funktion i Chrome DevTools med CPU throttling sat til 4x. Udrul ændringen og se LOAF-dimensionen opdatere inden for 24-48 timer med reel brugertrafik.

Tommelfingerregel for udviklere

• Enhver enkelt script-URL, der optræder i long frames for mere end 5 % af sessionerne, er værd at undersøge. Ved den frekvens påvirker det en målbar del af reelle brugere over hele måneden.
• Tredjeparts-scripts bør ikke køre under interaktionshåndteringer. Hvis en tag manager affyrer synkront på en klik-hændelse, er det et konfigurationsproblem, ikke en browserbegrænsning.
• En long frame-varighed på over 200ms 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 long frames under tilstandsopdateringer. 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 for, hvilke scripts der blokerer rigtige brugere i produktion, rangeret efter virkelighedens hyppighed. 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.