#858: deliveryType (Resource Timing)
Discussions
2023-07-17
[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
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
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
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-30
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
Yves: Tess and Rossen okayed closing this, satisfied
agree to close, Yves to write closing comment - agreed satisfied
OpenedJun 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:
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