Contact emails
Explainer
Specification
Design docs
Summary
Web applications may suffer from bimodal distribution in page load performance, due to factors outside of the web application’s control. For example:
* When a user agent first launches (a "cold start" scenario), it must perform many expensive initialization tasks that compete for resources on the system.
* Browser extensions can affect the performance of a website. For instance, some extensions run additional code on every page you visit, which can increase CPU usage and result in slower response times.
* When a machine is busy performing intensive tasks, it can lead to slower loading of web pages.
In these scenarios, content the web app attempts to load will be in competition with other work happening on the system. This makes it difficult to detect if performance issues exist within web applications themselves, or because of external factors.
Teams we have worked with have been surprised at the difference between real-world dashboard metrics and what they observe in page profiling tools. Without more information, it is challenging for developers to understand if (and when) their applications may be misbehaving or are simply being loaded in a contended period.
A new ‘confidence’ field on the PerformanceNavigationTiming object will enable developers to discern if the navigation timings are representative for their web application.
For this experiment, we are only supporting the "cold start" scenario described above.
Blink component
TAG review
TAG review status
Pending
Risks
Interoperability and Compatibility
None.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1191)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/469)
Web developers: No signals
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
Goals for experimentation
The noise added means that the 'confidence' field isn’t immediately useful to developers. Developers can collect this field in their Real User Monitoring (RUM) data and with enough records, correct the data to "eliminate the noise". One of the objectives of the experiment is to confirm developers are successfully able to do that. We're also interested in feedback about the API shape and ease of use.
Ongoing technical constraints
Debuggability
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
third_party/blink/web_tests/http/tests/misc/performance-navigation-timing-entry-confidence.tentative.html
Flag name on about://flags
Finch feature name
PerformanceNavigationTimingConfidence
Requires code in //chrome?
True
Tracking bug
Estimated milestones
Origin trial desktop first
136
Origin trial desktop last
139
DevTrial on desktop
135
Origin trial Android first
136
Origin trial Android last
139
DevTrial on Android
135
Link to entry on the Chrome Platform Status
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/o0F7nBKsgg0/m/bJSp3ekfAAAJ
Could you please request the privacy, security & debuggability bits in your chromestatus entry?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8357116e-470b-4a87-a816-bb24aa58f5cbn%40chromium.org.
Thanks.
LGTM to experiment from M135 to M139 inclusive (I think that's
what you've requested, at least).
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f5448cc4-5633-4181-a689-3566142330aen%40chromium.org.