Long Animation Frames (LoAF): How to Use It To Improve INP

With Interaction to Next Paint (INP) now an official Core Web Vital, efficiently measuring and debugging page responsiveness is more critical than ever. 

One of the go-to solutions when trying to fix a sluggish page is to identify and break long tasks that block the main thread. 

While this is a highly effective and (many would say) mandatory strategy, there might be a better, more comprehensive way to deal with INP issues.

Enter Chrome’s Long Animation Frames (LoAF) API. 

This relatively new tool is intended to help web developers and site owners better understand slow user interface updates.

Read on to learn why and how to add it to your performance toolbox.

What is a Long Animation Frame?

A long animation frame occurs when a frame in a webpage animation takes longer to render than the desired frame rate, often aimed at 60 frames per second, or 16.6 milliseconds.

For a website to appear smooth and fast, the browser needs to be able to update its content quickly. However, running many CPU-heavy tasks will block the browser’s main thread, delaying the rendering process and resulting in long animation frames. 

This delay, typically caused by complex animations and high-resolution graphics, leads to noticeable lag or jankiness, disrupting the smooth flow of the animation and creating a less responsive user experience.

You can see rendering frames in the Chrome DevTools Performance tab. The red entries show dropped frames, and the yellow entries show partially presented frames.

Why Long Animation Frames API: The Shortcomings of Long Tasks API

LoAF API builds upon another well-known and widely used tool – Long Tasks API.

Long Tasks API has been how developers identify and diagnose responsive issues for years.

First released in Chrome 58, it allows you to monitor long tasks (occupying the main thread for 50 milliseconds or longer) that prevent the browser from processing any other tasks or user interactions until completion.

However, it turned out that the Long Tasks API has some shortcomings:

• A long task does not include the part where the browser updates what you see on the screen (like animations or resizing). That phase includes requestAnimationFrame callbacks, resize observers, scroll observers, etc. So, even if these updates take a long time and make a website feel sluggish, they're not counted as a long task.
• Some operations, like UI events (e.g., clicks), that should be tasks are not specified or implemented to use long tasks. 
• A single task might do several things simultaneously, like handling multiple user interactions. This can make it hard to figure out exactly what part of a task is, causing it to take a long time.

In a nutshell:

• With Long Tasks API, the only information you get is that a long task occurred and how long it took the browser to process it. 
• As it turns out, it’s not the most complete and accurate way to measure main-thread blocking. 
• Hence, Chrome’s proposal of Long Animation Frames API.

What is Long Animation Frames API?​

The LoAF API is a proposed way to better measure and understand slow user interactions. 

Here’s how it works:

LoAF looks at how long the main thread is busy. It starts timing when the main thread begins any work and stops when it's either ready to display something or has nothing left to do (idle).

This time period can cover up to two tasks, including everything up to the point where the browser is ready to paint the screen with the updated content. This means it takes into account all the steps like:

• processing animations
• resizing elements
• painting pixels on screen

While INP is a big stride towards a more responsive web, it only shows you the effect but not the cause of the sluggishness. Whereas with LoAF, you can find out the exact time when the browser was congested, and also:

• How much time was spent in the different phases (rendering, layout-and-style);
• If there was any "layout thrashing, " period during which the website inefficiently calculated layout or styles multiple times, slowing things down;
• Whether the slow frame was blocking real-world user inputs – in other words, if it made the website unresponsive to clicks or typing;
• Details about any user scripts processed during the time of the frame (e.g., callbacks, event handlers, promise resolvers).

Advantages of Using LoAF API and Looking at Frames

1. Gives a bird’s-eye-view: The LoAF API offers a more complete view of what's happening on your website in terms of performance and responsiveness. It captures a broader range of factors that contribute to long animation frames. This comprehensive approach lets you see the complete picture of their website's performance.
2. Better attribution: One of the critical strengths of the LoAF API is its ability to provide detailed attribution for long frames. This means you can precisely identify what processes or elements are causing delays. Whether it's a particular script, an animation, or a complex CSS style, the API helps pinpoint the exact cause. 
3. Enhance user experience and satisfaction: Developers can significantly enhance the user experience by leveraging the LoAF API to identify and address long animation frames. Smooth animations and responsive interfaces are critical for user satisfaction.
4. Reduced bounce rates: Long animation frames can frustrate users, especially when they lead to janky animations or unresponsive pages. The LoAF API helps reduce user frustration by identifying and rectifying these issues. A website that performs well and responds quickly to user inputs is less likely to drive visitors away, thereby reducing bounce rates and improving the site's overall effectiveness.

We’re sure you can’t wait to test this new tool after all its benefits and advantages over Long Tasks API. So how could you do it? 
 

Using the Long Animation Frames API

LoAF is a proposed feature, so it’s not fully standardized yet. But you have two options to test it:

1. Enable Experimental Web Platform features in chrome://flags
2. Sign up for the LoAF API origin trial to enable it for your website and visitors

As far as how to test it, Chrome’s team has shared several ways depending on your goal:

Reporting long animation data back to an analytics endpoint

Here’s how you can monitor all long animation frames and flag the ones above a certain threshold back to an analytics endpoint for later analysis:

Observing the worst long animation frames

This is how you can receive the data only on the worst one, five, or however many long animation frames you want.

Reporting long animation frames with interactions

You can send the largest entries where an interaction occurred during the frame (which can be detected by the presence of a firstUIEventTimestamp value):

Surfacing long animation frames data in DevTools

You can reveal long animation frames in DevTools by utilizing the performance.measure() API. These frames will then appear in the DevTools user timings track within performance traces, highlighting where you should concentrate your performance enhancement efforts.

You can check all of the use cases in Chrome’s documentation.

Wrap Up

While still in the experimentation stage, LoAF API seems to offer plenty of benefits when it comes to boosting page responsiveness and INP score:

“We [Chrome team] believe that focusing on frames rather than tasks offers many benefits that make this a fundamentally different proposal to the existing Long Tasks API.”

But while LoAF has the upper hand over Long Tasks API,  there are no plans to deprecate the latter.

Nevertheless, if you’re interested in LoAF API, the Chrome team is seeking feedback to ensure it's easy to use and meets developers' needs before being released for general use. 

Feedback can be provided at the Long Task GitHub Issues list, or bugs in Chrome's implementation of the API can be filed in Chrome's issue tracker.