#858: deliveryType (Resource Timing)

Visit on Github.

Opened Jun 13, 2023

こんにちは 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).

Further details:

  • 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

Discussions

2023-07-03

Minutes

  • Breakout Rollup
2023-07-17

Minutes

[small delta? about to ship in chrome but in a web perf wg ED]

Amy: might be quick to review... bump to plenary

2023-07-mos-eisley

Minutes

Tess: First obvious feedback is that there are more than one type of cache. The opening paragraph is even explicit about that and at the same time it's hard to know how you would target a specific cache. It's unclear how you can use the capability to improve performance

Rossen: left commet pointing the authors to the https://w3ctag.github.io/caching-bundling-sustainability/ effort for considering how it might affect their proposal.

2023-08-21

Minutes

Yves: isn't the information served from the cache a possible issue? if you do that effectively but add some delay to make it so it doesn't look like it was served from the cache? we were discussing mitigations on double key cache and a way to use the cache without ... I would like to look at this

Rossen: we had a long conversation during the f2f that we didn't capture in notes...

2023-10-09

Minutes

Yves: we were wondering about the use of those values in case of solution for the cache sustainability issue where you might serve from the cache without telling that it's from the cache. You ahve to be careful about what information you surface or not at the js leve. They responded that they agree that they need to do something similar. Basically we should close satisfied.

Peter: fine with closing. Minor concern that if the apis are going to start lying about whether something came from the cache how useful is this?

Yves: if you're using double key cache instead of getting things from the network, but serving from the cache but with a delay, but in that case you won't say it's from the cache as well. But it's not really lying, it's just that it's not from the double key cache, it's from the navigator cache via delay used to fake the fact it should have been from the network but it's not from the network

Peter: so the effective performance is the same as what the reported performance is, it's just the mechanism is not.. I guess that makes sense

Yves: as we are mimicking not serving from the cache..

Peter: you're not getting the perf benefit of a cache, but you are getting the network savings. I can see people wanting to measure the effectiveness of that, but it's probably not worth exposing that

Yves: you can measure it if it's same origin. Just that if you are loading the same resource from another origin you probably don't want to share that information. Only in that case it matters, not in the perf case of loading the page for the first time or reloading the same page

Peter: makes sense. Close?

[proposed close - plenary]

2023-10-23

Minutes

Rossen: needs Tess... plenary?

2023-10-30

Minutes

Yves: proposed closing. Rossen wanted to sync up with Tess, not sure if something happened

Peter: I think they're working on it

2024-01-08

Minutes

Yves: Tess and Rossen okayed closing this, satisfied

agree to close, Yves to write closing comment - agreed satisfied