A slow interaction is rarely explained by one obvious function. Several modest tasks can run, style can be recalculated, layout can expand, and rendering can arrive late. The user experiences the combined result as a delayed click, a stuttering scroll, or an animation that misses frames.
The Long Animation Frames API gives developers a frame-level view of that work. Instead of reporting only individual long tasks, it records rendering updates that take more than 50 milliseconds and provides timing details that can help connect poor responsiveness to the scripts and layout work involved.
Frames reveal a different performance story
The Long Tasks API reports main-thread tasks that exceed 50 milliseconds. That signal remains useful, but a delayed render can also be created by several tasks that are individually shorter than the threshold. Looking at the frame as a whole exposes the cumulative delay between work beginning and the browser producing the visual update.
According to the Chrome Long Animation Frames guide, a long animation frame, often shortened to LoAF, is a rendering update delayed beyond 50 milliseconds. It can include script execution, animation callbacks, style calculation, layout, observer callbacks, and rendering work.
PerformanceObserver collects LoAF entries
Pages observe entries of type long-animation-frame with PerformanceObserver. Using the buffered option includes qualifying entries that occurred before the observer was created. Feature detection should check PerformanceObserver.supportedEntryTypes first because support is not universal.
The performance timeline keeps a limited buffer, so a live observer is more dependable than requesting all previous entries later. A sensible implementation records only the fields needed for diagnosis and applies sampling. Performance telemetry can grow quickly, and gathering every frame from every session is rarely necessary.
The timing breakdown points toward the cause
A LoAF entry contains its start time and total duration, plus milestones such as renderStart and styleAndLayoutStart. The blockingDuration estimates the portion that prevented higher-priority work from running, while firstUIEventTimestamp can show whether input arrived during the frame.
The entry's scripts array adds attribution for scripts that contributed to the delay. It can identify an invoker, source URL, function name, execution timing, and forced style or layout duration. The MDN Long Animation Frame timing reference documents these fields and their relationships.
LoAF data helps explain Interaction to Next Paint
Interaction to Next Paint measures the latency of user interactions across a visit. When an interaction is slow, a LoAF that overlaps it can reveal what occupied the main thread before the response was painted. The useful question is not merely which handler was slow, but what other scripts, callbacks, or layout work shared the same frame.
There is no simple one-property link between an INP entry and a LoAF entry. Their timing windows must be compared, and an interaction can occasionally span more than one long frame. Field tooling should keep that uncertainty visible rather than claiming perfect attribution.
Field evidence complements lab traces
DevTools and Lighthouse make controlled investigation easier, but they cannot reproduce every device, extension, network condition, content shape, or third-party script encountered by real visitors. LoAF entries can capture the context of slow frames in the field, helping a team decide which problems deserve a reproducible lab investigation.
Privacy discipline is essential. Avoid collecting page text, personal data, full URLs with sensitive parameters, or more script detail than the investigation requires. Aggregate results, limit retention, and document the measurement. Our PerformanceObserver guide covers the general observation pattern.
Measurement should lead to smaller units of work
Once a costly frame is understood, the fix depends on its shape. Large calculations may be split into smaller tasks, unnecessary style reads and writes can be grouped, heavy rendering can be simplified, and noncritical work can be deferred. The goal is to give important input and rendering opportunities room to run.
The Prioritized Task Scheduling guide explains how yielding and task priorities can help long JavaScript work cooperate with user-visible activity. For motion-specific problems, our Web Animations API guide discusses browser-managed playback and restrained interface motion.
Use LoAF as a diagnostic signal, not a score
Not every frame over 50 milliseconds has the same user impact. A slow frame during initial setup may matter less than one that traps a click or interrupts a scroll. Group entries by interaction context, route, device capability, and repeated script attribution. Prioritize patterns that affect real actions rather than chasing a zero count.
The Long Animation Frames API makes the browser's rendering delay more observable, but it does not replace careful testing or judgment. Used with targeted field sampling and reproducible traces, it can turn vague reports of “jank” into evidence about the frame, the script, and the layout work that users actually waited for.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.