search

w3c / compute-pressure

A web API proposal that provides information about available compute capacity
https://www.w3.org/TR/compute-pressure/
Other
69 stars 10 forks source link

Use-case: Analytics / RUM #233

Open nicjansma opened 9 months ago

nicjansma commented 9 months ago

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 commented 9 months ago

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!

kenchris commented 8 months ago

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.