Core/Dash Dimensie: LOAF

Dimensie: Long Animation Frames (lurl)

De LOAF-dimensie toont de URL's van scripts die Long Animation Frames veroorzaakten tijdens de sessies van uw gebruikers. Elke waarde is een script-URL: een first-party bundle, een third-party analytics tag, een chat widget, een consent manager, of wat er ook maar lang genoeg draaide om rendering te blokkeren. Dit is attributie op bronniveau, niet slechts een stack trace die u moet reconstrueren in DevTools.

CoreDash verzamelt deze data met behulp van de Long Animation Frames API (LoAF), die Chrome levert als vervanging voor de oudere Long Tasks API. Waar Long Tasks u vertelde dat een frame te lang duurde, vertelt LoAF u welke scripts binnen dat frame draaiden en wat hun URL's waren. Dat is het onderscheid dat deze dimensie nuttig maakt in productie.

Waarom Long Tasks niet genoeg waren

De Long Tasks API (beschikbaar sinds 2017) markeerde elke main thread taak die 50ms overschreed, maar gaf u vrijwel geen attributie. U kon zien dat er blokkering plaatsvond; u kon niet zien wat dit veroorzaakte. Ontwikkelaars spendeerden uren aan het correleren van taak-timestamps met network waterfalls, gissend naar welk script verantwoordelijk was.

De LoAF API verandert dit. Het rapporteert PerformanceLongAnimationFrameEntry objecten, die elk een scripts array bevatten. Elke entry in die array heeft een invokerType, een sourceURL en een duration. CoreDash leest de sourceURL voor elk script dat draaide tijdens een long frame en slaat dit op als de LOAF-dimensiewaarde. Het resultaat is een gerangschikte lijst van script-URL's, geordend op hoe vaak ze voorkomen in de long frames van uw gebruikers.

Hoe CoreDash LoAF-data gebruikt

Elke keer dat een gebruikersinteractie een long animation frame activeert, registreert CoreDash de bijdragende script-URL's naast de INP-observatie. Dit betekent dat u uw INP-data kunt filteren op LOAF-URL en kunt zien welk script verantwoordelijk is voor uw slechtste interacties. De dimensie groepeert op URL, zodat u een telling ziet van in hoeveel sessies dat script een long frame veroorzaakte.

Typische entries die u zult zien in de LOAF-dimensie:

• https://www.googletagmanager.com/gtm.js (Google Tag Manager container)
• https://cdn.cookielaw.org/consent/... (OneTrust of vergelijkbaar consent platform)
• https://js.intercomcdn.com/... (chat widget)
• /static/js/app.bundle.js (uw eigen applicatiecode)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

In CoreDash-data zijn third-party scripts verantwoordelijk voor long animation frames op ruwweg 60-70% van de sites. Tag managers alleen al dragen bij aan long frames op ongeveer 45% van de gemonitorde properties. First-party bundles domineren de rest, meestal als gevolg van React re-renders of ongeoptimaliseerde event handlers.

INP-attributie via LoAF

INP meet de tijd van gebruikersinteractie tot de volgende frame paint. Als dat gat 200ms overschrijdt, classificeert Google de ervaring als "needs improvement". De LoAF-data vertelt u welk script draaide gedurende dat gat. Een 280ms INP waarbij 210ms is te herleiden naar een consent manager script is een compleet ander probleem dan een 280ms INP waarbij 190ms is te herleiden naar uw eigen checkout handler. De fix is anders. Het verantwoordelijke team is anders. De urgentie is anders.

Zonder LoAF-attributie zien beide er identiek uit in uw INP-histogram. Met attributie kunt u het probleem direct naar de juiste persoon routeren.

Debugging Workflow

1. Open de LOAF-dimensie in CoreDash: Sorteer op frequentie (hoeveel sessies deze URL in een long frame zagen). De bovenste entry is uw doelwit met de hoogste prioriteit.
2. Cross-filter met INP: Pas het LOAF-filter toe op uw INP-metric view. Controleer of de INP p75 verandert wanneer u sessies isoleert waarin dat script draaide. Een toename van 30ms+ bevestigt dat het script bijdraagt aan INP-verslechtering in productie.
3. Classificeer als first-party of third-party: Uw eigen domein in de URL betekent dat u de controle heeft over de fix. Een third-party CDN URL betekent dat u het vendor-script moet verwijderen, vertragen of vervangen.
4. Pas de fix toe en verifieer: Voor third-party scripts, stel het laden uit tot na de eerste gebruikersinteractie met behulp van een facade of delayed init. Voor first-party code, profileer de specifieke functie in Chrome DevTools met CPU-throttling ingesteld op 4x. Implementeer de wijziging en kijk hoe de LOAF-dimensie zich binnen 24-48 uur aanpast op basis van echt gebruikersverkeer.

Vuistregel voor engineering

• Elke afzonderlijke script-URL die in long frames verschijnt voor meer dan 5% van de sessies is het onderzoeken waard. Op dat niveau beïnvloedt het een meetbaar deel van echte gebruikers gedurende de maand.
• Third-party scripts zouden niet moeten draaien tijdens interaction handlers. Als een tag manager synchroon triggert bij een click event, is dat een configuratieprobleem, geen browserbeperking.
• Een long frame-duur van meer dan 200ms voor een enkel script is een duidelijk signaal. De LoAF API rapporteert de duur per script binnen het frame. Elk script dat 200ms of meer van een frame verbruikt, is de primaire oorzaak van de INP die daarop volgt.
• First-party scripts in de LOAF-lijst wijzen vaak op framework overhead. React, Vue en Angular kunnen allemaal long frames produceren tijdens state updates. De LoAF-URL zal uw eigen bundle zijn. Profileer de component tree, niet alleen het netwerk.

De LOAF-dimensie geeft u iets dat geen enkele synthetische test kan: bewijs van welke scripts echte gebruikers in productie blokkeren, gerangschikt op frequentie in de echte wereld. Filter erop, kruisvergelijk met uw INP-data, en u heeft een geprioriteerde lijst van exact wat u moet oplossen en in welke volgorde.