deliveryType (Resource Timing)

[jeremyroman]

こんにちは TAG-さん!

I'm requesting a TAG review of deliveryType (part of Resource Timing).

Resources on the web are usually fetched via HTTP (from the origin server), but in some cases they are known to be delivered from a cache or other buffer, in a way that affects loading performance. Insight into this is useful for authors understanding when these caches accelerate resource loading. The deliveryType attribute on PerformanceResourceTiming addresses this, with the following values: "" (no more specific delivery type applies), "cache" (the resource was served from the cache), "navigational-prefetch" (the resource was prefetched for navigation from another page).

• Explainer¹ (minimally containing user needs and example code): https://gist.github.com/jeremyroman/43f8f290f1f404d3b7f6cb708601c7f0
• Specification URL: https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-deliverytype
• Tests: resource-timing/delivery-type.tentative.any.js, speculation-rules/prefetch/navigation-timing-delivery-type.tentative.https.html
• User research: no formal research, though a developer has used this API without significant difficulty in origin trial
• Security and Privacy self-review²: https://gist.github.com/jeremyroman/43f8f290f1f404d3b7f6cb708601c7f0#file-security-privacy-questionnaire-md
• Primary contacts (and their relationship to the specification):
  • Jeremy Roman (@jeremyroman), Google LLC
  • William Liu (@superliuxz), Google LLC
• Organization(s)/project(s) driving the specification: Google LLC
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Web Performance Working Group (e.g., 2022-02-03, 2022-04-28, w3c/resource-timing#343, w3c/navigation-timing#163
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://chromestatus.com/feature/6347141115543552

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: I am hoping to ship this single attribute addition relatively soon in Chrome. It has previously been discussed in the WPWG context, but as part of this process it was suggested that we get TAG's opinion as well. A quick response would be appreciated; I hope that given the small scope of this feature and prior attention that significant revision won't be necessary.
• The group where the work on this specification is currently being done: Web Performance Working Group
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Web Performance Working Group
• Major unresolved issues with or opposition to this specification: none known
• This work is being funded by: Google LLC

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @jeremyroman

[jeremyroman]

Anticipating one possible question -- the type of the attribute is DOMString. Since this values is only provided to clients and not accepted from them, I believe this is indistinguishable from an enum from the author's perspective, and was chosen for consistency with most other values exposed on this object.

If an enum would be preferred (I believe this is still forward-compatible for the addition of new types in the future), that seems like a change that would be possible to make to the specification without any change to author code.

[hober]

Since there are more than one kind of cache, is the single "cache" value sufficient?

[atanassov]

An effort that needs to be considered is the Sustainability of Bundling and Caching. In case that privacy approach becomes adopted your proposed API should probably apply similar heuristics and "masking" of the results.

[jeremyroman]

There are many kinds of cache, yeah. In the context of PerformanceResourceTiming I think it's most natural to describe the HTTP cache (whether it has one layer or multiple), and that's what people usually seem to mean by "the cache" in this context.

Some caches (e.g., an image decode cache) probably don't make sense to describe as part of resource loading.

Some caches (e.g., a caching forward proxy, reverse proxy or CDN) are outside the user agent proper and I would think probably don't make sense to describe here (but server timing might be appropriate). If we did want to describe it in deliveryType in the future, I think it would be natural for it to have a different enumerator.

The service worker and preload caches are probably the two most potentially interesting cases I'm aware of. Consuming resources from the preload cache isn't currently exposed, and if it were to be (w3c/resource-timing#303), I think a separate enumerator would be justified and would be reasonably clear, since it's generally not described as a "cache" elsewhere in its API (deliveryType: "preload" or similar).

---

re. sustainability of bundling and caching, there doesn't seem to be enough detail there yet to strongly reason about its implications if adopted, but if it becomes necessary to obscure the cache state of certain resources I agree that similar masking might be applicable here. I would hope that at same-origin resources, at least, wouldn't require such masking.

[ylafon]

Sorry it took a long time to close this, but as hinted above, we don't have any issue with this.