search

WICG / element-timing

A proposal for an Element Timing specification.
https://wicg.github.io/element-timing/
Other
57 stars 15 forks source link

Rather than add tagging attributes to elements, allow to "get timings for all elements" via flag. #68

Open DerGernTod opened 2 years ago

DerGernTod commented 2 years ago

Since LCP heavily relies on element timing, I wonder how exactly it does that, since it would need the timings of all elements on the page that could have a visual impact. This would also be interesting for third party performance analytics software to determine, say, the slowest X visible elements and their URLs. Is this feasible? I imagine an approach similar to LCP with a buffered flag where I can pull element timings at any given point in time and use that data to analyze rendering performance culprits. Maybe even a flag that allows to set the buffer size, e.g. only store slowest X entries.

yoavweiss commented 2 years ago

@npm1 for opinions on feasibility. I suspect the cost of keeping track of all element paints would be too high, but I'm not sure if this is something we already looked into.

It'd be interesting to understand specific use-cases that this would enable - if there's cost then a strong use case can potentially offset it.

npm1 commented 2 years ago

It seems feasible but also somewhat costly because there are certain computations that are only done in Element Timing (LCP does not expose the rects), and we'd need to create timing entries for everything (very costly). Storing the "slowest X entries" does not make a lot of sense: slowest according to what? There can be a stream of incoming new elements (due to animations/user input etc.) so it's not clear what you mean by that.

npm1 commented 2 years ago

Slowest X before user input could work, I guess. But not clear why you want slowest instead of largest, or some other criteria?