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 je 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 dan ook lang genoeg draaide om rendering te blokkeren. Dit is attributie op bronniveau, niet slechts een stack trace die je 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 je vertelde dat een frame er te lang over deed, vertelt LoAF je welke scripts er 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 de 50ms overschreed, maar gaf je vrijwel geen attributie. Je kon zien dat er een blokkade optrad; je 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, elk met een scripts array. 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 je gebruikers.

Hoe CoreDash LoAF data gebruikt

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

Typische entries die je 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 (je eigen applicatiecode)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

In CoreDash data zijn third-party scripts verantwoordelijk voor long animation frames in ongeveer 60-70% van de sites. Tag managers alleen dragen al 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 vanaf een gebruikersinteractie tot de volgende frame paint. Als dat gat groter is dan 200ms, classificeert Google de ervaring als "needs improvement." De LoAF-data vertelt je welk script er draaide tijdens dat gat. Een INP van 280ms waarbij 210ms te herleiden is naar een consent manager script is een compleet ander probleem dan een INP van 280ms waarbij 190ms te herleiden is naar je 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 je INP-histogram. Met attributie kun je het probleem onmiddellijk naar de juiste persoon routeren.

Debugging Workflow

1. Open de LOAF-dimensie in CoreDash: Sorteer op frequentie (hoeveel sessies zagen deze URL in een long frame). De bovenste entry is je doelwit met de hoogste prioriteit.
2. Kruisfilter met INP: Pas de LOAF-filter toe op je INP metric-weergave. Controleer of de INP p75 verandert wanneer je sessies isoleert waarin dat script draaide. Een stijging van 30ms+ bevestigt dat het script bijdraagt aan INP-verslechtering in productie.
3. Classificeer als first-party of third-party: Je eigen domein in de URL betekent dat jij de fix beheert. Een third-party CDN URL betekent dat je het vendor-script moet verwijderen, vertragen of vervangen.
4. Pas de fix toe en verifieer: Voor third-party scripts stel je het laden uit tot na de eerste gebruikersinteractie met behulp van een facade of vertraagde initialisatie. Voor first-party code profileer je de specifieke functie in Chrome DevTools met CPU throttling ingesteld op 4x. Implementeer de wijziging en kijk hoe de LOAF-dimensie binnen 24-48 uur aan real user traffic wordt bijgewerkt.

Engineering Vuistregel

• 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 de echte gebruikers gedurende de maand.
• Third-party scripts mogen niet draaien tijdens interactiehandlers. Als een tag manager synchroon afvuurt op een klikgebeurtenis, is dat een configuratieprobleem, geen browserbeperking.
• Een long frame-duur van meer dan 200ms voor één 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 welke INP er ook 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 je eigen bundle zijn. Profileer de componentenboom, niet alleen het netwerk.

De LOAF-dimensie geeft je iets dat geen synthetische test kan: bewijs van welke scripts echte gebruikers in productie blokkeren, gerangschikt op praktijkfrequentie. Filter erop, kruis het met je INP-data, en je hebt een geprioriteerde lijst van exact wat je moet fixen en in welke volgorde.