How does Event Timing API relate to/overlap with Long Tasks API?

[mmocny]

The Long Tasks api overlaps with Event Timing in some ways, and folks have asked for increased clarity. Here's a start:

Similarities:

• Measuring Long Tasks is meant to help predict and prevent issues with Responsiveness and Smoothness of UIs-- which is directly measured with Event Timing. The use cases overlap.

  • Abstract for Long Tasks API:

    This document defines an API that web page authors can use to detect presence of "long tasks" that monopolize the UI thread for extended periods of time and block other critical tasks from being executed - e.g. reacting to user input.

  • Abstract for Event Timing API:

    This document defines an API that provides web page authors with insights into the latency of certain events triggered by user interactions.

• Both measure time spent blocking JS main thread:

  • processingStart + processingEnd from Event Timing and startTime + duration of Long Tasks both expose "task time"
  • The same task timings may be exposed to both API at the same time.

• Both have the concept of a durationThreshold (though the meaning differs). 50ms (fixed, non-configurable) for Long Tasks and 104ms (default, configurable within limits) for Event Timing

  • Represents just main thread processing time for Long Tasks, represents total timeStamp to next paint duration for Event Timing.

Differences:

• Event Timing reports timeStamp of events (via startTime). Long Tasks does not.
• Event Timing reports total duration measured all the way until next paint. Long Tasks does not.
• The property names used for process times differ:
  • processingStart and processingEnd in Event Timing vs startTime and durationin Long Tasks api.
  • startTime and duration are already used by Event Timing for a different meaning.
• Event Timing durationThreshold is relative to the total event latency (timeStamp to next paint) not just processing times.
• Event Timing durationThreshold is configurable on PerformanceObserver options.
• (As a direct consequence of above) Event Timing may report events which have very little direct processing time.
• Many different event types may fire (and be reported) for the same "next paint", even when there is only a single long task.
• The name value of each api differs greatly: the event.type vs task origin/context
• Long Tasks attempts to record attribution

I've likely missed a lot of differences. Net/net, there are long tasks which are reported for things outside events, and events reported even with tasks are not long... but it is also the case that some of the features already overlap and some more overlap may even be desired.

[mmocny]

A few more additions:

• Event Timing reports "Long Frames" which happen to have events as part of the work that went into that frame.
• (Really) Long Frames will typically have some number of Long Tasks, but it isn't guaranteed. There are multiple steps to generating a single animation frame and many of them are split across independent Tasks. Plus time spend off-main thread.
• Many Long Tasks appear outside of the context of Animation Frames (i.e. during idle time). These are inherently less interesting or important. Event timing, and Element timing, highlights these critical moments.

[noamr]

How would a really long frame have more than two tasks? you mean e.g. the compositor is blocking?

[mmocny]

Hypothetical example:

• Task 1: random task running on main when an event arrives
• Task 2+: Event Dispatch for new Input.
  • If there are multiple inputs at the same time-- as could be common if the first task was really long and we have built up a queue, any number of inputs may get dispatched.
• Task 3: After event processing is finish, a may slips in before rendering starts.
  • Typically we prioritize rendering, but it may not get scheduled in time.
• Task 4+: Rendering itself
  • Within the Rendering task, we also dispatch more rAF-aligned events (e.g. mousemove, scroll), and other callbacks: requestAnimationFrame, Fullscreen, Resize, Intersection observers... At least some of this may (should?) get accounted as separate tasks.

Of course, we have before covered that the Long Tasks API can group things in unexpected ways, so I wanted to run some experiments...

---

Now. You nerd-sniped me real bad with this question as I tried to create a test page to showcase what happens in practice.

What I'm finding is that the Long Task API is even odder than I expected, such that I may need to sync up with you to understand what the design intent really is. I have found that it sometimes merges tasks together across boundaries I was not expecting.

For example, my test page always schedules work in 50ms increments, only one 50ms task per platform entry point (i.e. 50 per input, 50 per animation frame callback, etc). I can easily end up with Long Frames (~1 second long), and tracing shows many independent tasks, as I expect. Yet, I still only get ~2 Long Tasks reported per frame (as you suggested).

Here is a trace to showcase what I mean. I will focus on the Frame which starts at ~9280ms in the timeline.

You can see that DevTools CrRendererMain nests "tasks" in different ways:

• ThreadController::active
• Task
• Actual functions (WidgetBaseInputHandler::OnHandleInputEvent, ProxyMain::BeginMainFrame, etc)
• Specific Event Handlers/callbacks

The LongTasks API seems to always "slice" that middle Task in half and report that. I always get 2x Long Tasks entries as I get those Tasks:

But I don't understand what concept that maps to...

Here's a closer look at the main thread activity...

First half:

Second half:

---

I'll upload the demo and we can chat, but I want to clean it up a bit more.

[mmocny]

So, seems I can regularly create 3-4 Long Tasks per frame outside of Interactions... perhaps because on Chrome we don't prioritize rendering work more often than every 100ms, or after input.

But I also finally recorded trace with 3 long tasks in a frame which had Input.

Link to Trace, you can find that frame @740ms

[noamr]

OK these are actually 1-2 tasks per frame, with 3-4 long scripts in a task. DevTools marks both of them as long (because why not?)

The UI events spec does not specify a relationship between UI events and the event loop. This leaves a lot of room to optimize and differentiate in implementations. Those differences are not web-observable.... except in the long tasks API in some scenarios.

If to follow the spec literally, the language is usually in the format of "A user agent MUST dispatch event FOO when some conditions are met" (see mousemove).

This is usually implemented as:

• If there's pending input, post a task to read pending inputs
• when that task starts, check all pending inputs for events to dispatch
• update the rendering etc.

The above is spec-compliant but not spec-mandated.

So in essence, both in spec and in chromium, we could currently have a max of (1 task + update the rendering) per frame.

[noamr]

IMO he differences in the OP are not inherent to the nature of long tasks and event timing... A lot of them are API decisions that could be interchangeable between the two APIs. e.g. we could have event timing attribution or set the durationThreshold of long tasks if we wanted to. ... another difference is that event-timing is per-iframe and longtasks is only for the top level window. But it's again somewhat of an artificial difference.

The main difference between event timing and long tasks is that long tasks measure potential blockages and event timing rely on actual user behavior (UI events). An additional difference is the rare case where event timing would be long without a long task/frame, and also event timing deals with interactionId for INP.

Seems to me that apart from the above rare cases, event timing entries would be a subset of long task attribution (especially if we use long-frames rather than long-tasks) with additional information specific to UI events.

---

But the way I make sense of this is by looking at long tasks/frames and event-timing as two views into an overlapping dataset. One is focused on "am I hogging the main thread in a way that can delay animation frames or interaction feedback?" and the other one is "what's the journey a UI event has to go through from input until feedback?" The first one is a diagnostic and the second one more of a regression test. So creating separate observers for them also makes some sense. We should perhaps start viewing event types as different views into a timeline rather than separate "APIs".

[noamr]

To summarize thoughts:

• long tasks measures cause
• Event timing measures effect

Equivalent to how resource timing measures cause and paint timing measures effect.

Because of what we know about long tasks and events, long tasks are likely to be the root cause of long event timing. However, this is not a given and should not be assumed. There could be long tasks that don't create long events, and there could be long events not created by long tasks.

[mmocny]

Cause vs Effect is one way to summarize.

Event Timing also exposes metadata specific to events:

• timeStamp (and thus input delays)
• the portion of main thread time dedicated to processing just the event handlers
• target node ...and today Event Timing also exposes the renderTime (via duration) which probably should have been reported by Paint Timing / LoAF instead.

I don't know if those are fair to label as "effect" so much as "The event's contribution to cause, which mostly may have came from other things in the LoAF" or something like that.

[clelland]

@noamr, do you think there are spec changes to be made here to clarify this in Event TIming?

[mmocny]

I think we've documented a bunch of this, and LoAF has made lots of progress.

Here is one document: https://github.com/w3c/long-animation-frames?tab=readme-ov-file#overlap-with-event-timing