Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

LOAF-dimensionen visar URL:er för skript som orsakade Long Animation Frames under dina användares sessioner. Varje värde är en skript-URL: ett förstaparts-bundle, en tredjeparts-analystagg, en chattwidget, en samtyckeshanterare eller vad som helst som kördes tillräckligt länge för att blockera renderingen. Detta är attribuering på källnivå, inte bara en stacktrace du måste rekonstruera i DevTools.

CoreDash samlar in denna data med Long Animation Frames API (LoAF), som Chrome levererar som en ersättare för det äldre Long Tasks API. Där Long Tasks berättade att en frame tog för lång tid, berättar LoAF vilka skript som kördes i den framen och vad deras URL:er var. Det är den skillnaden som gör den här dimensionen användbar i produktion.

Varför Long Tasks inte räckte till

Long Tasks API (tillgängligt sedan 2017) flaggade alla tasks på main thread som överskred 50 ms, men gav nästan ingen attribuering. Du kunde se att blockering skedde, men inte vad som orsakade den. Utvecklare la timmar på att korrelera tidsstämplar för tasks med nätverksvattenfall och gissa vilket skript som var ansvarigt.

LoAF API ändrar på detta. Det rapporterar PerformanceLongAnimationFrameEntry-objekt, som var och ett innehåller en scripts-array. Varje post i den arrayen har en invokerType, en sourceURL och en duration. CoreDash läser sourceURL för varje skript som kördes under en lång frame och sparar det som LOAF-dimensionens värde. Resultatet är en rankad lista över skript-URL:er, sorterad efter hur ofta de förekommer i dina användares långa frames.

Hur CoreDash använder LoAF-data

Varje gång en användarinteraktion utlöser en lång animations-frame, registrerar CoreDash de bidragande skript-URL:erna tillsammans med INP-observationen. Det betyder att du kan filtrera din INP-data efter LOAF-URL och se vilket skript som är ansvarigt för dina sämsta interaktioner. Dimensionen grupperar efter URL, så att du ser antalet sessioner där skriptet orsakade en lång frame.

Typiska poster du ser i LOAF-dimensionen:

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

I CoreDash-data står tredjepartsskript för långa animations-frames på ungefär 60–70 % av alla sajter. Enbart tagghanterare bidrar till långa frames på cirka 45 % av de övervakade sajterna. Förstaparts-bundles dominerar resten, oftast på grund av React-re-renders eller ooptimerade event handlers.

INP-attribuering via LoAF

INP mäter tiden från användarinteraktion till nästa frame-rendering. Om det gapet överstiger 200 ms klassar Google upplevelsen som ”needs improvement”. LoAF-data berättar vilket skript som kördes under det gapet. En INP på 280 ms där 210 ms kan spåras till ett skript för en samtyckeshanterare är ett helt annat problem än en INP på 280 ms där 190 ms kan spåras till din egen checkout-hanterare. Lösningen är en annan. Det ansvariga teamet är ett annat. Prioriteringen är en annan.

Utan LoAF-attribuering ser båda identiska ut i ditt INP-histogram. Med den kan du skicka vidare problemet till rätt person direkt.

Felsökningsflöde

1. Öppna LOAF-dimensionen i CoreDash: Sortera efter frekvens (hur många sessioner som såg den här URL:en i en lång frame). Den översta posten är ditt högst prioriterade mål.
2. Korsfiltrera med INP: Applicera LOAF-filtret på din vy för INP-metrik. Kontrollera om INP p75 ändras när du isolerar sessioner där skriptet kördes. En ökning med 30 ms eller mer bekräftar att skriptet bidrar till INP-försämringen i produktion.
3. Klassificera som förstaparts eller tredjeparts: Din egen domän i URL:en betyder att du kontrollerar lösningen. En tredjeparts CDN-URL betyder att du behöver ta bort, fördröja eller byta ut leverantörsskriptet.
4. Applicera åtgärden och verifiera: För tredjepartsskript, skjut upp laddningen till efter den första användarinteraktionen med en fasad eller fördröjd initiering. För förstapartskod, profilera den specifika funktionen i Chrome DevTools med CPU-throttling inställd på 4x. Driftsätt ändringen och se LOAF-dimensionen uppdateras inom 24–48 timmar av verklig användartrafik.

Teknisk tumregel

• Varje enskild skript-URL som förekommer i långa frames under mer än 5 % av sessionerna är värd att undersöka. Med den frekvensen påverkar det en mätbar andel verkliga användare under månaden.
• Tredjepartsskript bör inte köras under interaktionshanterare. Om en tagghanterare körs synkront vid ett klick-event är det ett konfigurationsproblem, inte en begränsning i webbläsaren.
• En varaktighet för en lång frame på över 200 ms för ett enskilt skript är en tydlig signal. LoAF API rapporterar varaktighet per skript inuti framen. Alla skript som konsumerar 200 ms eller mer av en frame är den primära orsaken till den INP som följer.
• Förstapartsskript i LOAF-listan pekar ofta på ramverksoverhead. React, Vue och Angular kan alla skapa långa frames under state-uppdateringar. LoAF-URL:en kommer att vara din egen bundle. Profilera komponentträdet, inte bara nätverket.

LOAF-dimensionen ger dig något som inget syntetiskt test kan: bevis på vilka skript som blockerar verkliga användare i produktion, rankade efter verklig frekvens. Filtrera efter den, korsreferera med din INP-data, så har du en prioriterad lista över exakt vad du ska åtgärda och i vilken ordning.