Hi @guohuideng2024, the TAG reviewed this and fount it much more plausible than the previous approach. The overall mechanism looks highly feasible to us.

We have some comments at a lower level regarding the API design.

1. The proposed new APIs markCondition() and measureConditional() are directly tied to long animation frames, and therefore:
   • The connection between these APIs and LoAF is not clear from the names and may be confusing
   • This is not extendable to use cases like, e.g., we want to analyze long tasks instead of long animation frames, or if there are new types of performance incidents we want to introduce in the future
2. We are also unsure why we need to introduce "conditional" marks and measures, instead of somehow allowing existing marks and measures to be attributed to LoAF and similar incidents.

Hi @guohuideng2024 - did you or the group have any response to the TAG's comments?

cc: @noamr

Apologies for the late reply!

1. "long task" is monitored/reported by LoAF. A single long task is sufficient to emit a LoAF. Therefore, after this feature is implemented the conditional user timing can analyze long tasks.

2. Our intention is that "conditional user timing" is not only tied to LoAF(Long animation frame), but a collection of Performance reporting API. "LoAF" is the very first Performance reporting API that monitors and includes these user timing points. Thus, we use a very general word "conditional". And we do intend to expand this to other user cases, like EventTiming or even ElementTiming in the near future.

3. We use a new name/API like markConditional instead of expanding the existing performance.mark, based on a number of considerations.

   a) They behavior very different from regular performance.mark/measure: There is no overlap between where regular mark/measure can appear and where these conditional user timing can appear; conditional user timing points and regular user timing points never interact each other(both interact within the same kind); the conditional user points (after the future expansion) operates in parallel in a number of different timelines; even the implementation of conditional user timing has very little overlap of that for user timing.

   So, conditional user timing is a completely new breed of user timing, unlike anything that existed before.

   b) We want the app developers to be able to deploy more such user timing points, so the user timing points must be lightweight, with minimal performance overhead. Unfortunately, the existing performance.mark/measure has a so large collection of functionalities built in, that operations on them cost too much CPU and memory (for example, sorting is required even for a performance.mark). Therefore, we explicitly want to exclude these Options in the existing Performance.mark/measure. By using a new API/name it's clear that the interface is different.