You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
The text was updated successfully, but these errors were encountered:
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!
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
changed the title
Analytics / RUM use cases?
Use-case: Analytics / RUM
Nov 9, 2023
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 inPerformanceObserver
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!
The text was updated successfully, but these errors were encountered: