Tracking Long Animation Frames

The long-animation-frame entry type (LoAF) reports any rendering frame that took longer than 50ms to produce and, unlike a bare long task, attributes the cost to the specific scripts that ran inside it. It is the most precise field signal for diagnosing slow interactions and has largely superseded longtask for INP work. This builds on PerformanceObserver API Patterns, part of Rendering Performance Metrics and Tooling.

What a LoAF Entry Contains

A long task only tells you the main thread was blocked for some duration in some frame. A LoAF entry frames the same stall around the render loop and exposes the structure of where the time went: how long was spent in scripts versus rendering versus style-and-layout, when rendering started, and a scripts array attributing slices to individual call sites.

blockingDuration is the field most directly tied to interaction latency. Where longtask made you subtract 50ms by hand to estimate blocking, LoAF computes the input-blocking portion for you, accounting for frames where multiple tasks stacked up before the browser could render.

The entry lays the whole frame out on a single timeline, so each field is really a boundary marker between phases. Reading them left to right shows exactly where the 16.6ms budget was blown:

Minimal Reproduction

// A handler that mutates state, then does heavy synchronous work in the same frame
input.addEventListener('input', (e) => {
  state.query = e.target.value
  // ❌ Expensive filter runs inside the rendering frame, delaying paint of the result
  results = catalogue.filter((item) => deepMatch(item, state.query)) // ~90ms
  renderResults(results)
})

The interaction’s visual update — the filtered list — cannot paint until this 90ms block finishes, so the user sees a frozen field and the frame is recorded as a long animation frame.

Observing LoAF and Its Script Attribution

const obs = new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    if (frame.blockingDuration > 0) {
      report({
        duration: frame.duration,
        blocking: frame.blockingDuration,    // input-blocking ms in this frame
        scripts: frame.scripts.map((s) => ({
          src: s.sourceURL,                  // file that owned the slice
          fn: s.invoker,                     // e.g. 'input.onclick'
          ms: s.duration,
          forcedLayout: s.forcedStyleAndLayoutDuration, // sync layout cost
        })),
      })
    }
  }
})
obs.observe({ type: 'long-animation-frame', buffered: true }) // replay early frames

The scripts array is what makes LoAF actionable. A long task says “118ms in window”; a LoAF says “90ms in search.js input.oninput, of which 12ms was forced style and layout.” That last figure points straight at a forced synchronous layout hiding inside the handler.

Why It Supersedes longtask for INP

INP is dominated by the worst interaction’s three phases: input delay, processing time, and presentation delay. A longtask entry overlaps the processing phase but ignores presentation delay and gives no attribution, so it cannot tell you whether the slow part was your event handler or the rendering that followed. LoAF spans the whole frame — renderStart separates script time from render time — and its scripts array names the culprit. That is exactly the breakdown you need when correlating with the per-interaction data from Measuring INP with the Event Timing API.

Laid over the same interaction, the coverage gap is obvious: longtask clips the processing phase and stops, while LoAF wraps input delay through presentation and carries per-script attribution alongside it.

Debugging Trace

[Long Animation Frame — 'input' interaction]
  frame start ............................. t=0
├─ scripts[0] search.js input.oninput .... 90.0ms
│    └─ forcedStyleAndLayoutDuration ...... 12.0ms  (sync layout inside filter)
├─ renderStart .......................... t=90ms   ← paint delayed 90ms
├─ style + layout ........................ 4.0ms
└─ paint ................................. 3.0ms
   duration: 97ms  blockingDuration: 47ms
   Frame budget 16.6ms exceeded — INP for this interaction ≈ 97ms+

The Fix

Move the heavy work off the rendering frame: yield so the input can paint an immediate acknowledgement, then compute. Splitting the synchronous slice both shrinks blockingDuration and lets the result paint progressively.

input.addEventListener('input', (e) => {
  state.query = e.target.value
  showSpinner() // ✅ cheap synchronous update paints this frame
  // Defer the expensive filter out of the rendering frame
  queueMicrotask(async () => {
    results = await filterInChunks(catalogue, state.query) // yields between chunks
    renderResults(results) // paints in a later, short frame
  })
})

If forcedStyleAndLayoutDuration is the dominant slice, the real fix is batching DOM reads and writes so the handler stops flushing layout mid-loop — the LoAF entry has already located it for you.

The structural change is turning one blocking frame into a short acknowledgement frame plus deferred chunks, each short enough to slip under the 50ms LoAF threshold:

Verification Checklist

• No long-animation-frame entry with blockingDuration > 50ms during the interaction.
• The scripts array no longer lists the handler as a 90ms slice.
• forcedStyleAndLayoutDuration is near zero — no synchronous layout in the loop.
• The interaction’s INP, correlated through Event Timing, sits under 200ms.

Why LoAF Beats Long Tasks for Animation Work

The Long Animation Frames API exists because the older Long Tasks API answers the wrong question for rendering work. A long task flags any single script execution over 50ms, but jank is rarely one 50ms task — it is often a frame made slow by several shorter scripts, a forced layout, and a heavy style recalculation that individually stay under the long-task threshold yet together blow the frame budget. LoAF measures the whole frame: it reports when a rendering update took too long regardless of how the time was distributed, and it attributes the cost across scripts, style, layout, and paint. That framing matches how animation actually fails, which is why it is the better instrument for tracking smoothness.

The attribution LoAF provides is what makes it actionable. Each entry carries the frame’s start time, its duration, the time blocked, and a breakdown of the scripts that ran, including their source location and whether they were classic event listeners, promise resolutions, or timers. In the field this turns a vague “the page feels janky” into “these specific handlers are extending frames past budget on this route,” which is a work item rather than a mystery. Pairing LoAF with the INP attribution from the Event Timing API gives a near-complete picture of interaction smoothness: one tells you which frames ran long and why, the other tells you how that translated into the latency a user felt when they interacted.

Frequently Asked Questions

Related Guides

• PerformanceObserver API Patterns — the parent guide covering buffered flags, entry types, and observer lifecycle.
• Measuring INP with the Event Timing API — correlate the per-interaction latency that LoAF explains.
• Forced Synchronous Layouts — fix the forcedStyleAndLayoutDuration slice a LoAF entry exposes.