Intent to Ship: PerformanceSoftNavigation and InteractionContentfulPaint performance entry
Michal Mocny
Contact emails
mmo...@chromium.org, shas...@chromium.org, yoav...@chromium.org
Explainer
https://github.com/WICG/soft-navigations
Specification
https://wicg.github.io/soft-navigations
Summary
Adds "soft-navigation" and "interaction-contentful-paint" PerformanceEntry types to the web performance timeline to track interaction-driven page performance, including for "soft" navigations (JS-driven navigations in Single Page Apps (SPAs)). This work expands on metrics like Largest Contentful Paint (LCP) and Interaction to Next Paint (INP).
The "interaction-contentful-paint" entry reports on new contentful paints within parts of the page modified by a user interaction, helping developers understand interaction loading latency. This proposal tracks the effects of interactions across async tasks (like fetch requests).
The "soft-navigation" entry reports same-document history state changes initiated by interactions, establishing a new time origin to correctly attribute subsequent performance data to the active route rather than the initial document URL.
Blink component
Web Feature ID
No information provided
Motivation
Web developers have been asking for a way to measure the loading performance of "soft navigations" (JS-driven navigations in Single Page Apps (SPA)), and to integrate such navigations into the web performance timeline in general.
Besides getting useful new performance insights for these, having a shared standard definition for such navigations helps attribution for all existing performance timeline data (i.e. resource timings), and provides better default aggregation for metrics like INP or CLS with better URL attribution.
Initial public proposal
https://github.com/WICG/proposals/issues/71
TAG review
https://github.com/w3ctag/design-reviews/issues/879
TAG review status
Pending
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/47
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://issues.chromium.org/issues/40229587
https://github.com/WICG/proposals/issues/71
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?
None known. This feature is part of the standard performance timeline, which is available in WebView in the same way as non-webview. The feature is entirely implemented within blink + renderer.
Debuggability
No information provided
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name on about://flags
soft-navigation-heuristics
Finch feature name
SoftNavigationHeuristics
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1338390
Availability expectation
Feature is available only in Chromium browsers for the foreseeable future. This is relatively common for Performance APIs, where the requirement for Baseline support is lower. A performance API can be feature detected and used only on Chromium and still give developers great value.
That said, there is existing Baseline support for the foundations of this work: Event Timing, Paint Timing, and LCP-- and it seems there is relatively positive support for the nascent AsyncContext and Container Timing features which may make interop progress in the next year. Thus we expect a future where this set of APIs also reaches interop/Baseline status.
Adoption expectation
At least 3 major abstractions replace their use of an existing feature with this feature within 24 months of reaching mainline. Specifically, several RUM measurement products and/or frameworks rely on custom instrumentation, web platform api monkey-patching, and/or developer hints in order to measure interactions and soft-navigations. These APIs have been fairly widely deployed during origin trial by many partners/abstractions, and we expect that these APIs are broadly adopted over the next few years.
Adoption plan
This feature has been in demand for years, and has been widely discussed in relevant web performance groups (w3c web perf working group, rum community group, slack, conferences, etc). Many organizations have already participated in multiple rounds of OT. This feature is also expected to power the next major update to the Core Web Vitals program, and has already been integrated into an experimental branch of the web-vital.js library which has wide industry adoption (making it an easier integration/upgrade).
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
No.
Estimated milestones
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
The API shape has gone through multiple rounds of iteration and is expected to be in its final form. There may be future API extensions added to expose more features (i.e. to add more "container timing" details) but the API was designed to gracefully support this.
Note: the spec currently does not limit this API only the main frame top level document, but the chromium implementation does. We expect to change the implementation to expose InteractionContentfulPaint also to frames, but may change the spec to limit SoftNavigation entries (due to complexity of history stack).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5144837209194496?gate=4820517475844096
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 2: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69cd703e.050a0220.319665.006a.GAE%40google.com
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.