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

Allow to reset the INP calculation #448

Open
Mattstir opened this issue Mar 27, 2024 · 4 comments
Open

Allow to reset the INP calculation #448

Mattstir opened this issue Mar 27, 2024 · 4 comments

Comments

@Mattstir
Copy link

Hi,

it would be awesome if the package would offer a resetINP function or something similar.

Use case
We would need this feature as we take a look at the "subpages" of SPAs as individual pages and would be highly interested in the individual INP values of them. Because of the way the entries are collected in longestInteractionList this of course is not really possible.

Possible Solution
I guess clearing prevInteractionCount, prevInteractionCount, longestInteractionMap in this new reset function should be enough? Or do I miss something here?

Value
This clear function would allow for more different use cases (in combination with the already present reportAllChanges: true) while increasing the complexity and package size only slightly. I think this is a valuable addition!
Thanks!

@tunetheweb
Copy link
Member

Hi @Mattstir , we're not looking to add this functionality to this library at this time for the reasons explained here: #433 (comment)

However, while we appreciate the potential usefulness of this change to allow SPAs to manually measure CLS and INP per route, we do have some concerns with accepting this into the web-vitals library:

First up, the intent of the library (as given in the Overview) is for:

measuring all the Web Vitals metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. Chrome User Experience Report, Page Speed Insights, Search Console's Speed Report).

By reseting CLS and INP you will affect the overall "hard-nav" CLS and INP that can be reported.

This is also part of why the soft branch support has not been merged either.

Secondly, the "measuring all the Web Vitals metrics" is a key point. By only making CLS and INP available (which I agree is all that CAN be made available given Chrome itself will not reset LCP or FCP), we think this will lead to confusion, or a certain expectation that they will be available.

But let's leave this issue open so others can comment.

FYI: @spetroll

@Mattstir
Copy link
Author

Hi @tunetheweb
Thanks for the quick answer.
And despite that's not what I was hopping for I fully understand that reasoning.

PS: Thanks for providing this useful package! :)

@szymekz
Copy link

szymekz commented Oct 11, 2024

Hi @tunetheweb, while I largely agree with the discussion about reporting vitals for the entire visit, I believe that measuring INP (Interaction to Next Paint) in Single Page Applications (SPAs) presents a significant challenge.

In SPAs, users often engage in extensive browsing sessions, and frequently, they may not directly land on certain pages from search engine results. This scenario creates a situation where we lack the opportunity to measure INP for these specific pages in isolation if we adhere strictly to the current approach. The INP metric, being cumulative for the whole visit, doesn't provide granular insights into individual page performance.

To address this, we may need to somehow "reset" the metric at appropriate intervals. Our current analytics reflect this issue, as we observe that statistics for different pages are remarkably similar, offering little insight into which specific pages require improvement.

This situation highlights the need for a more nuanced approach to measuring and reporting INP in the context of SPAs, ensuring we can gather meaningful, page-specific performance data.

@tunetheweb
Copy link
Member

As well as being able to reset the metrics we'd need to be able to attribute the events (which are often delivered after the fact) back to the navigation at the time of the event. This requires underlying work in the browser before this library can truly support SPAs.

You can plus one this issue to help us prioritise this work: https://issues.chromium.org/issues/40229587

However, even then the current plan is for this to be a heuristic-based soft navigations, rather than a reset option. See: https://developer.chrome.com/blog/soft-navigations-experiment/

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