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

Use-case: Analytics / RUM #233

Open
nicjansma opened this issue Sep 16, 2023 · 2 comments
Open

Use-case: Analytics / RUM #233

nicjansma opened this issue Sep 16, 2023 · 2 comments
Labels

Comments

@nicjansma
Copy link

Hi!

I was wondering if there was consideration for using this API for measuring and segmenting the performance of browsing sessions, e.g. via Real User Monitoring (RUM) tools.

For example, I could see the compute pressures of fair/serious/critical being an important signal for segmenting user experiences during scenarios like Page Load, or in-page SPA Soft Navigations. It's likely those buckets will see degraded browsing performance, and users of RUM could slide/dice/filter by the Compute Pressure to better understand good and bad experiences.

When reviewing and testing out the current PressureObserver API, one thing that would be useful would be to be able to gather "buffered" entries that have happened prior to requesting. This is a pattern we use in PerformanceObserver for RUM when those RUM tools load "late" in the page-load process, so they can "look back" and get details back in history.

https://w3c.github.io/performance-timeline/#performanceobserverinit-dictionary

Without buffered entries, when RUM tools initialize, if they start a PressureObserver they can't know the "current" (or past) state of compute pressure for that browsing session, until the pressure state changes.

Would a buffered flag be compatible with the goals and privacy/security concerns of this API?

Side question, was there any discussion of just using the PerformanceObserver API directly?

Thanks!

@anssiko
Copy link
Member

anssiko commented Sep 20, 2023

Thanks for the proposals. The current API is designed with long-running tasks in mind and would not report appropriate pressure state transitions for experiences whose duration is relatively short. This is by design. We've put significant effort to mitigate all known privacy concerns and have a mitigation in place that would make what you'd need not feasible. This is a tradeoff between privacy protections and "expressiveness" of the API.

As a v2 feature, the API could possibly provide a way to opt-in to a more fine-grained reporting (e.g. with a user's express consent) to cater to use cases such as Page Load and Soft Navigations. I'll triage this as v2 to be discussed with the group, including investigation into PerformanceObserver API interactions. You bring up many great points. Thanks!

@anssiko anssiko added the V2 label Sep 20, 2023
@kenchris
Copy link
Contributor

kenchris commented Nov 6, 2023

I don't think there are privacy issues if the page was focused during the time until the observation was initiated. The biggest issue is that we only enable the hardware telemetry when the developer starts observing as it is not entirely free, but maybe it is neglectable - we would have to measure that.

@kenchris kenchris changed the title Analytics / RUM use cases? Use-case: Analytics / RUM Nov 9, 2023
@arskama arskama mentioned this issue Sep 18, 2024
29 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants