Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
DerGernTod opened this issue Dec 7, 2021 · 3 comments

Comments

@DerGernTod
Copy link

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.

@DerGernTod DerGernTod changed the title Rather than add tagging attributes, allow to "get timings for all elements" via flag. Rather than add tagging attributes to elements, allow to "get timings for all elements" via flag. Dec 7, 2021
@yoavweiss
Copy link
Collaborator

@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
Copy link
Collaborator

npm1 commented Dec 13, 2021

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
Copy link
Collaborator

npm1 commented Dec 13, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants