-
Notifications
You must be signed in to change notification settings - Fork 102
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
Attributing impact on Web Vitals 🧪 #98
Comments
Thanks for starting the conversation @addyosmani! :)
Definitely reliant on functionality in Lighthouse first since we don't get access to raw traces in HTTPArchive, but we can discuss approaches here before bringing a proposal there 👍
Please correct me if I'm wrong, but I had thought that this audit and trace event data marks the elements that shifted which is usually not the same as why they shifted. I think what we would want here is for Chrome to expose the IDs of the new content that reflowed the shifting elements down. I'm not sure it's a solvable problem but it would be neat to try.
This also feels very difficult, but I think @connorjclark worked on some stacktrace "find where this DOM element came from" magic that might apply here. I think the tricky part is going to be getting the attribution in the middle of the page load which is what I expect you really need for CLS.
This sounds great asssuming we can tackle the other two :) |
yup! https://chromedevtools.github.io/devtools-protocol/tot/DOM/#method-getNodeStackTraces we could collect stack traces for all the things in |
TPW currently does a great job capturing the execution costs of individual third-party scripts.
I'm curious if there's a mechanism we can define for measuring the impact these third-parties have on web vitals. As an example, let's take CLS:
For each Lighthouse run via HTTP Archive/WPT:
Is this crazy-talk, @patrickhulce ? :)
The text was updated successfully, but these errors were encountered: