Intent to Ship: deliveryType (Resource Timing)
Jeremy Roman
Contact emails
Explainer
https://gist.github.com/jeremyroman/43f8f290f1f404d3b7f6cb708601c7f0
Specification
https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-deliverytype
Summary
Expose information about how a resource was delivered. For example, resources which were delivered from the cache (currently exposed through transferSize) and navigations which were prefetched by the previous page are useful to identify.
This is currently part of an experiment bundled with other features (because it is necessary to be able to tell whether a page was prefetched to evaluate the utility of prefetching technology), but I believe it's useful to ship independently, and need not be tied to the areas that remain under development/experimentation/discussion.
Blink component
Blink>PerformanceAPIs>ResourceTiming
TAG review
https://github.com/w3ctag/design-reviews/issues/858
TAG review status
Pending
Risks
Interoperability and Compatibility
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/824)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/204)
Web developers: No public signals, but web.dev and developer.chrome.com were able to successfully use deliveryType to distinguish prefetch from non-prefetch traffic. The major hiccup encountered was the origin trial token not being processed before the deliveryType property was accessed; this difficulty would not exist when the feature is shipped.
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?
Debuggability
Some of this information is already visible to developers in the Network panel. Developers can use the JavaScript console to access the deliveryType API.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/?label=master&label=experimental&aligned&q=delivery-type
Flag name
No user-visible flag; DeliveryType runtime-enabled feature.
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1358591
Estimated milestones
Anticipated spec changes
Future changes may add additional delivery types, which would be initially unrecognized by author code - most likely, real user metrics software and services. For example, w3c/resource-timing#303 discusses the possibility of exposing "consume a preload" events on the performance timeline; it might treat this as a separate timing event with a new delivery type. Until this software recognizes this new delivery type, it might report misleading data until it is updated, depending on how it handles unknown values.
Some user agents already redact timing related information more than is required by spec; such user agents may hide the delivery type of resources in such cases, and this may introduce interop risk which is likely to manifest as a distortion of the data collected rather than a user-visible bug.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6347141115543552
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cZU8%3D7Ka3SWSf4E2dgDuhRRBRt_fGgDeC6d%3DqHP%3Durrw%40mail.gmail.com
Intent to experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/3-0rLTZePzc/m/VNHWAdAGDQAJ
Intent to extend experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/L3mpXE1x3Zk/m/6Lko5dPKAgAJ
This intent message was generated by Chrome Platform Status.
Rick Byers
Contact emails
Explainer
https://gist.github.com/jeremyroman/43f8f290f1f404d3b7f6cb708601c7f0
Specification
https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-deliverytype
Summary
Expose information about how a resource was delivered. For example, resources which were delivered from the cache (currently exposed through transferSize) and navigations which were prefetched by the previous page are useful to identify.
This is currently part of an experiment bundled with other features (because it is necessary to be able to tell whether a page was prefetched to evaluate the utility of prefetching technology), but I believe it's useful to ship independently, and need not be tied to the areas that remain under development/experimentation/discussion.
Blink component
Blink>PerformanceAPIs>ResourceTiming
TAG review
https://github.com/w3ctag/design-reviews/issues/858
TAG review status
Pending
Risks
Interoperability and Compatibility
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/824)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/204)
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eeaznd8kGyT1LvfiZCUSnRgR2CQeo0eo5dM1h8J%3DBqiw%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_CkafTSUA34y1SFN0ZZGhBNEV6phcQ7ejdkt9Y%2BOrDQw%40mail.gmail.com.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEEWjnaVCu23r%2B5SXg65OJdW83FasTuM0a0fvVbKDRVw%40mail.gmail.com.