Core/Dash Dimension: LOAF

Dimension: Long Animation Frames (lurl)

The LOAF dimension surfaces the URLs of scripts that caused Long Animation Frames during your users' sessions. Each value is a script URL: a first-party bundle, a third-party analytics tag, a chat widget, a consent manager, or whatever else ran long enough to block rendering. This is attribution at the source level, not just a stack trace you have to reconstruct in DevTools.

CoreDash collects this data using the Long Animation Frames API (LoAF), which Chrome ships as a replacement for the older Long Tasks API. Where Long Tasks told you a frame took too long, LoAF tells you which scripts ran inside that frame and what their URLs were. That is the distinction that makes this dimension useful in production.

Why Long Tasks Were Not Enough

The Long Tasks API (available since 2017) flagged any main thread task exceeding 50ms, but it gave you almost no attribution. You could see that blocking happened; you could not see what caused it. Developers spent hours correlating task timestamps with network waterfalls, guessing which script was responsible.

The LoAF API changes this. It reports PerformanceLongAnimationFrameEntry objects, each containing a scripts array. Every entry in that array has an invokerType, a sourceURL, and a duration. CoreDash reads the sourceURL for each script that ran during a long frame and stores it as the LOAF dimension value. The result is a ranked list of script URLs ordered by how often they appear in your users' long frames.

How CoreDash Uses LoAF Data

Every time a user interaction triggers a long animation frame, CoreDash records the contributing script URLs alongside the INP observation. This means you can filter your INP data by LOAF URL and see which script is responsible for your worst interactions. The dimension groups by URL, so you see a count of how many sessions involved that script causing a long frame.

Typical entries you will see in the LOAF dimension:

• https://www.googletagmanager.com/gtm.js (Google Tag Manager container)
• https://cdn.cookielaw.org/consent/... (OneTrust or similar consent platform)
• https://js.intercomcdn.com/... (chat widget)
• /static/js/app.bundle.js (your own application code)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pixel)

In CoreDash data, third-party scripts account for long animation frames in roughly 60-70% of sites. Tag managers alone contribute to long frames on approximately 45% of monitored properties. First-party bundles dominate the remainder, usually due to React re-renders or unoptimized event handlers.

INP Attribution via LoAF

INP measures the time from user interaction to the next frame paint. If that gap exceeds 200ms, Google classifies the experience as "needs improvement." The LoAF data tells you which script ran during that gap. A 280ms INP where 210ms traces to a consent manager script is a completely different problem than a 280ms INP where 190ms traces to your own checkout handler. The fix is different. The team responsible is different. The urgency is different.

Without LoAF attribution, both look identical in your INP histogram. With it, you can route the issue to the right person immediately.

Debugging Workflow

1. Open the LOAF dimension in CoreDash: Sort by frequency (how many sessions saw this URL in a long frame). The top entry is your highest-priority target.
2. Cross-filter with INP: Apply the LOAF filter to your INP metric view. Check whether the INP p75 changes when you isolate sessions where that script ran. A 30ms+ increase confirms the script is contributing to INP degradation in production.
3. Classify as first-party or third-party: Your own domain in the URL means you control the fix. A third-party CDN URL means you need to either remove, delay, or replace the vendor script.
4. Apply the fix and verify: For third-party scripts, defer loading until after the first user interaction using a facade or delayed init. For first-party code, profile the specific function in Chrome DevTools with CPU throttling set to 4x. Deploy the change and watch the LOAF dimension update within 24-48 hours of real user traffic.

Engineering Rule of Thumb

• Any single script URL appearing in long frames for more than 5% of sessions is worth investigating. At that rate, it is affecting a measurable portion of real users across the month.
• Third-party scripts should not run during interaction handlers. If a tag manager fires synchronously on a click event, that is a configuration problem, not a browser limitation.
• A long frame duration above 200ms for a single script is a clear signal. The LoAF API reports per-script duration inside the frame. Any script consuming 200ms or more of a frame is the primary cause of whatever INP follows.
• First-party scripts in the LOAF list often point to framework overhead. React, Vue, and Angular can all produce long frames during state updates. The LoAF URL will be your own bundle. Profile the component tree, not just the network.

The LOAF dimension gives you something that no synthetic test can: proof of which scripts block real users in production, ranked by real-world frequency. Filter by it, cross-reference with your INP data, and you have a prioritized list of exactly what to fix and in what order.