And underneath it, it shows the same segment, but highlighting the different sections of work executed in that animation frame. First, you may notice that we have multiple events in one single animation frame. I'll get back that I'll get back to it further ahead. But keep in mind that an animation frame and subsequently, IMP metric and the long animation frame entries are not limited to one event per interaction. So I can actually let me see if I can have this. There you go. So here is the same kind of segment within the performance tab. And you can see for this particular trace, you have different animation frames here, right? So within that, we can check, for instance, if I scroll for this particular animation frame, I have different types of work executed within one animation frame. And it's not always just scripting.
Now back to the presentation. It is also important to note that part of the attribution model may not be present in some animation frame, such as the missing attribution slots you have into the image there. That might be due to different limitations currently faced by the platform to accurately or safely infer the information, such as execution time coming from third-party scripts or Chrome extensions. So now let's take a look at different attributes from the animation frame attribution model, but how it's present into the IMP metric. You might have seen one of these little guys within the interaction track on the performance panel, where on the left and the right whiskers are the inputs and presentation delay. The solid bar in the middle is the processing time.
Let's start with the first UI event, timestamp. This is part of the attribution model within animation frames, coming from the Long Animation Frame API. But it also is known as the input delay. This is the timestamp for the first event, the first interaction event to be processed within a given animation frame. This timestamp represents the interaction event creation and might have happened at any point in time within the current or previous animation frame, depending if there was a delay between the event being created and the event being processed. These attribute provides the data used to calculate the input delay for animation frames that are connected to the IMP event. The processing time encompasses work on the main thread related to tasks or microtasks that are executed during the animation frame. If inspected in the profiler, this group of work will be represented on the flame graph by work such as script compilation, different function calls and callbacks, promise execution, timer callback functions, and also forced style and layouts.
The last section of work before the browser can produce a ship in the next frame is the presentation delay. It consists of any work related to processing visual updates needed after the main thread has finished executing all tasks of the animation frame. This type of work is composed of different parts like style and layout. But style layout is not the only type of work being processed at this stage. Other different APIs are executed between a task execution and the frame being presented on the screen. Work such as CSS selector evaluation and styling computation, precise observer callbacks, view transition promises, and request animation frame callbacks. The work executed at this stage runs a lot closer to the parts of the animation frame that involves presenting a new frame, but they also can contribute to delays before the new frame can be presented, since some of those APIs may also spawn its own microtasks, thus work executed at this stage can also lead to IMP problems.
Comments