Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

LOAF-dimensionen lyfter fram URL:erna för skript som orsakade Long Animation Frames under dina användares sessioner. Varje värde är en skript-URL: en förstaparts-bundle, en tredjeparts-analystagg, en chattwidget, en consent manager, 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 stack trace som du måste rekonstruera i DevTools.

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

Varför Long Tasks inte räckte till

Long Tasks API (tillgängligt sedan 2017) flaggade alla uppgifter på huvudtråden som översteg 50 ms, men det gav dig nästan ingen attribuering. Du kunde se att blockering skedde; du kunde inte se vad som orsakade den. Utvecklare spenderade timmar på att korrelera uppgifternas tidsstämplar med nätverksvattenfall och gissade vilket skript som var ansvarigt.

LoAF API ändrar på detta. Det rapporterar PerformanceLongAnimationFrameEntry-objekt, som vart 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 lagrar det som LOAF-dimensionens värde. Resultatet är en rankad lista över skript-URL:er ordnade 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 long animation frame, registrerar CoreDash de bidragande skript-URL:erna tillsammans med INP-observationen. Detta innebär att du kan filtrera din INP-data efter LOAF-URL och se vilket skript som är ansvarigt för dina sämsta interaktioner. Dimensionen grupperas efter URL, så du ser ett antal på hur många sessioner som involverade att det skriptet orsakade en lång frame.

Typiska poster du kommer att se 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 long animation frames på ungefär 60-70 % av webbplatserna. Tag managers ensamma bidrar till långa frames på cirka 45 % av övervakade egendomar. Förstaparts-bundles dominerar resten, vanligtvis på grund av React-omrenderingar eller ooptimerade händelsehanterare.

INP-attribuering via LoAF

INP mäter tiden från användarinteraktion till nästa frame paint. Om det gapet överstiger 200 ms klassificerar Google upplevelsen som "needs improvement". LoAF-datan berättar för dig vilket skript som kördes under det gapet. En INP på 280 ms där 210 ms kan spåras till ett consent manager-skript är ett helt annat problem än en INP på 280 ms där 190 ms kan spåras till din egen utcheckningshanterare. Lösningen är annorlunda. Det ansvariga teamet är annorlunda. Brådskan är annorlunda.

Utan LoAF-attribuering ser båda identiska ut i ditt INP-histogram. Med det kan du dirigera problemet till rätt person omedelbart.

Arbetsflöde för felsökning

1. Öppna LOAF-dimensionen i CoreDash: Sortera efter frekvens (hur många sessioner som såg denna URL i en lång frame). Den översta posten är ditt högst prioriterade mål.
2. Korsfiltrera med INP: Tillämpa LOAF-filtret på din INP-mätvy. Kontrollera om INP p75 ändras när du isolerar sessioner där det skriptet kördes. En ökning på över 30 ms bekräftar att skriptet bidrar till INP-försämring i produktion.
3. Klassificera som förstapart eller tredjepart: Din egen domän i URL:en innebär att du kontrollerar lösningen. En tredjeparts CDN-URL innebär att du antingen måste ta bort, fördröja eller byta ut leverantörsskriptet.
4. Tillämpa lösningen och verifiera: För tredjepartsskript, skjut upp inläsningen tills efter den första användarinteraktionen med hjälp av en fasad eller fördröjd initiering. För förstapartskod, profilera den specifika funktionen i Chrome DevTools med CPU-strypning inställd på 4x. Distribuera ändringen och se hur LOAF-dimensionen uppdateras inom 24-48 timmar av verklig användartrafik.

Teknisk tumregel

• Varje enskild skript-URL som förekommer i långa frames för mer än 5 % av sessionerna är värd att undersöka. I den takten påverkar den en mätbar andel av verkliga användare under månaden.
• Tredjepartsskript bör inte köras under interaktionshanterare. Om en tag manager avfyras synkront vid en klickhändelse, är det ett konfigurationsproblem, inte en webbläsarbegränsning.
• En varaktighet för en lång frame över 200 ms för ett enskilt skript är en tydlig signal. LoAF API rapporterar varaktighet per skript inuti framen. Alla skript som förbrukar 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å ramverks-overhead. React, Vue och Angular kan alla producera långa frames under tillståndsuppdateringar. 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 riktiga användare i produktion, rankade efter frekvens i den verkliga världen. Filtrera på det, korsreferera med din INP-data, så har du en prioriterad lista över exakt vad du ska åtgärda och i vilken ordning.