Intent to Extend Experiment: SoftNavigation performance entry

14 views
Skip to first unread message

Chromestatus

unread,
3:21 PM (3 hours ago) 3:21 PM
to blin...@chromium.org, mmo...@chromium.org, shas...@chromium.org
Contact emails
mmo...@chromium.org, shas...@chromium.org, yoav...@chromium.org

Explainer
https://github.com/WICG/soft-navigations
https://github.com/WICG/soft-navigations/blob/main/Design.md

Specification
https://wicg.github.io/soft-navigations

Summary
Exposes the (experimental) soft navigation heuristics to web developers, using both PerformanceObserver and the performance timeline. This feature reports two new performance entries: - "soft-navigation", for user interactions which navigate the page. Defines a new timeOrigin to help slice the performance timeline. - "interaction-contentful-paint", which reports on the loading performance of interactions (beyond just next paint), used as LCP for soft-navigations.

Blink component
Blink>PerformanceAPIs

Web Feature ID
No information provided

TAG review
https://github.com/w3ctag/design-reviews/issues/879

TAG review status
Issues addressed

Origin Trial Name
Soft Navigation Heuristics

Goals for experimentation
1. Gaining insights on the quality of the heuristic and how it compares to current heuristics employed, from web developers, spa-framework authors, and by existing RUM providers; Focusing specifically on the initial "soft-navigation" reporting and the "interaction-contentful-paint" loading entries that follow. 2. Learning if developers find the correlation of various existing performance entries (i.e. Resource Timings, CLS or INP entries) to these soft navigation entries more useful than without them.

Chromium Trial Name
SoftNavigationHeuristics

Link to origin trial feedback summary
https://github.com/WICG/soft-navigations/issues

Origin Trial documentation link
https://github.com/WICG/soft-navigations#soft-navigations

Risks


Interoperability and Compatibility
No information provided

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/854)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/235)

Web developers: Strongly positive https://github.com/WICG/proposals/issues/71#issuecomment-1325856231 https://twitter.com/yoavweiss/status/1575191332775026688

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided


Reason this experiment is being extended
Requesting a 3 milestone extension to this feature. Reason: provide developers the opportunity to test several significant changes to the API shape following the most recent Origin Trial (OT) feedback (details below). Also, multiple developers have requested the opportunity to participate in a new OT period, as they were unable to complete testing before the previous deadline. While we considered moving directly to shipping, the substantial implementation changes that followed the first OT we think will benefit from another round of developer feedback to ensure a stable launch. (We also have remaining specification/documentation work to do). Major changes since end of previous OT: - InteractionContentfulPaint performance entry now reports for ALL interactions, and reports BEFORE soft navigation performance entry is emitted. I.e. its a general responsiveness metrics as well as a navigation loading metric. - Integrated with Event Timing interactions, and both SoftNavigation and InteractionContentfulPaint now receive an `interactionId` value to match. - Added support for replaceState, and expose `navigationType` to the api (top developer requested feature change) Minor changes: - Adjusted the navigation startTime to match the interaction event timing startTime (i.e. Event hardware timeStamp). This will make reported timings look larger, but more consistent with existing Interaction metrics (and existing tooling) - Many more "under the hood" improvements that further improve detection rates and paint reporting quality. Field data results from the latest versions look incredibly promising (and we hope to share some insights publicly at BlinkOn, soon).

Reason this experiment is being extended
We are still collecting feedback from partners, who are evaluating the suitability of this API to replace existing ad-hoc methods of measuring soft navigations, including some who were only recently able to start experimenting. Additionally, we have made changes to the heuristics, in response to testing and feedback, to eliminate some false-positive detections, and better match the behaviour of real-world single-page apps. Some of these changes initially went out in Chrome 120, and were refined in Chrome 121; some will be released with Chrome 122. We'd like to give developers a chance to experiment with these changes, to help inform any future adjustments that need to be made. After Chrome 123, we intend to pause the experiment while we act on all of the feedback, and decide whether further changes to the heuristics are necessary, or if the API is in good enough shape to consider shipping.

Reason this experiment is being extended
This feature has already gone through two origin trials which ended in milestone 123 a year ago. We took developer feedback and communicated with web developers at the end of the trial with the following status: "The Chrome team are taking time to review the experiment feedback and consider the next steps for this API. We want to address some accuracy issues and believe another origin trial will be required before the feature is ready to progress." Over the next year we investigated the reasons for the deficiencies, updated the implementation, and revamped the proposed API slightly. I have created a description of these changes here: https://github.com/WICG/soft-navigations/issues/47 Early results (local lab testing, and field histograms in aggregate) from the current version of the feature shows a significant improvement from a year ago, and we've gotten positive anecdotal feedback from some early testers on Canary with experimental features enabled. Although this feature has already had 2 Origin trials, because there has been over a year of gap since the last trial, we request permission for another 6 milestones extension, rather than 3, which are necessary as we expect it will take developers some time ramp up and collect sufficient field data to analyze give feedback, and for us to iterate on this feedback.

Ongoing technical constraints
None.

Debuggability
No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No

Is this feature fully tested by web-platform-tests?
Yes


Flag name on about://flags
No information provided

Finch feature name
SoftNavigationHeuristics

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1338390

Estimated milestones
Origin trial desktop first139
Origin trial desktop last144
Origin trial extension 1 end milestone123
Origin trial extension 2 end milestone149
Origin trial extension 3 end milestone123
Origin trial extension 4 end milestone144
Origin trial Android first139
Origin trial Android last144
Origin trial WebView first139
Origin trial WebView last144


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144837209194496?gate=5090983379337216

Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3qRFx0i-eGJFSzqE8bnbX8XYJCvXAj0LfvO0icPo_jA%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUb_Gn_5gGy8SnChg5KH2JN57Gv0NhnHN7Q_kH0Aa17CQ%40mail.gmail.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/g/blink-dev/c/xxrmKr-6X38/m/48Hri1cnAgAJ
Intent to Extend Experiment 3: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfULP5d3fNCAqeO2gLP56R3HCytmaNk%2B9kpYsC2dj4%3DqoQ%40mail.gmail.com
Intent to Extend Experiment 4: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEeF2TfyN4LMy2DQwjPrsTekEw8dNXgcqiogvznagjtWyfqixA%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Michal Mocny

unread,
4:15 PM (2 hours ago) 4:15 PM
to Chromestatus, blin...@chromium.org, mmo...@chromium.org, shas...@chromium.org
(The automated email removed my message formatting, and its a bit confusing to read through the full history.  For your benefit, here is a formatted copy focusing on the new request)

Requesting a 3 milestone extension to the Origin Trial for this feature (m147 - m149).

Reason:
  • Provide developers the opportunity to test several significant changes to the API shape following the most recent Origin Trial (OT) feedback (details below).
  • Also, multiple developers have requested the opportunity to participate in a new OT period, as they were unable to complete testing before the previous deadline.
  • While we considered moving directly to shipping, the substantial implementation changes following the first OT will benefit from another round of developer feedback to ensure a stable launch.
  • (We also have remaining specification and documentation work to complete).
Major changes since the end of the previous OT:
  • InteractionContentfulPaint performance entry now reports for ALL interactions, and reports before the soft navigation performance entry is emitted.
    • I.e. It's a general responsiveness metric as well as a navigation loading metric.
  • Integrated with Event Timing interactions, and both SoftNavigation and InteractionContentfulPaint now receive an `interactionId` value to match.
  • Added support for `replaceState` and exposed `navigationType` to the API (a top developer-requested feature change)
Minor changes:
    • Adjusted the navigation startTime to match the interaction event timing startTime (i.e. Event hardware timeStamp).
      • This will make reported timings appear larger, but be more consistent with existing Interaction metrics (and existing interaction performance measurement tooling).
    • Many more "under the hood" improvements further improve detection rates and paint reporting quality.
    Field data results from the latest versions look incredibly promising (and we hope to share some insights publicly at BlinkOn, soon).
    Reply all
    Reply to author
    Forward
    0 new messages