GoogleChrome / web-vitals

Essential metrics for a healthy site.
https://web.dev/vitals
Apache License 2.0
7.47k stars 410 forks source link

CLS and INP are being calculated incorrectly #465

Closed psabharwal123 closed 4 months ago

psabharwal123 commented 4 months ago

Chrome measures CLS as all layout shift bursts within a 5s that are not more than 1s apart. However this library continues to report CLS entries that are more than 5s apart using the same id. As a result users who stay on a page for long time nd up with very big CLS values which is not reflective of what is seen in CrUX reports

Similarly for INP, it should report the longest event that is part of a single interaction, but new INP entries are generated for different interactions and they all have same id, so user ends up with a very big INP when we sum up all metric deltas

i would expect layout shift more than 5s apart to have different id, same for INP from different interactions

tunetheweb commented 4 months ago

The id is a "per-page" and "per-metric" id. It is expected to remain the same throughout the life of the page because the metric is expected to be reported once per page.

The delta will be the changed amount, even if you are using reportAllChanges (which I guess you are using, as you noted that in your original issue, but then removed it in an edit).

However do be careful when passing the metric object around and make sure you are not updating it and THEN using that updated object to extra the delta as the object may have changed in the meantime. I've seen cases of this happening.

If you still believe there is an issue here then please provide an example of where this happens.

psabharwal123 commented 4 months ago

thanks for the quick reply, we did't realize that metric object was being changed by subsequent layout shifts.