resource-timing
resource-timing copied to clipboard
w3c
Expose delivery type in PerformanceResourceTiming.
This is an attempt to address both w3c/navigation-timing#163 and #303 by exposing a deliveryType attribute on PerformanceResourceTiming (as mentioned in https://github.com/w3c/resource-timing/issues/303#issuecomment-1099078362), specifically the entry that may consume (rather than populate) a cache. This doesn't preclude timing entries being available for the request which populates the cache, if appropriate.
It would be one of the following DOMStrings:
"navigational-prefetch", which would be used for the cases in w3c/navigation-timing#163. Algorithms which use a prefetched response during navigation would call mark resource timing with this delivery type."preload", which would be passed by consume a preloaded resource"cache", which would apply if the cache mode is non-empty (i.e., the resource came from the cache)- the empty string, if none of the above apply. We could alternatively call this
"network"or similar, but this has precedent in cache mode, is perhaps less misleading if new delivery types aren't immediately supported, and is false-ish, similar to if the the property is absent.
"navigational-prefetch" could be temporarily left out of the spec proper and instead kept as a monkey-patch in the proposals for specifying navigational prefetch, but I've included it for now.
"preload" could also land as a separate normative change coordinated with its own HTML and WPT pull requests.
@yoavweiss @noamr Trying to unblock these two issues; wdyt?
The delta to this specification is fairly small: https://github.com/w3c/resource-timing/compare/gh-pages...jeremyroman:resource-timing:resource-timing-prefetch?expand=1
Right now, consuming a preloaded resource doesn't create an entry. Modifying that would require some discussion, which started in #303. IIUC, your proposal here matched @noamr's "separate entry" proposal. Is that correct?
Yes, I propose that consuming a preloaded resource create a separate entry, like Noam's separate entry proposal.
Yes I think we should have separate entries for each fetch and separate them by something like this proposal. Not sure how to advance towards a consensus on #303 though.
I defer to you and Yoav about what the right process is within Web Perf WG (CONTRIBUTING.md seems to say "enough support" after review by WG participants), but it seems like a proposal like this one would:
- make it easy for authors/RUM libraries to filter out the preload consume records if they wanted to
- be consistent with how cached resources work, give flexibility moving forward about whether/how to expose the timing of the underlying navigational prefetch itself (whether it's shown to the referring page, the destination page, neither or both), and
- address the problem in w3c/navigation-timing#163 (
performance.getEntriesByType('navigation')[0].deliveryType === 'navigational-prefetch')
My preferred way of making forward progress is to make a concrete proposal (this one, adapted from the linked comment), solicit feedback (maybe this needs to go to a WPWG F2F? unsure about process) and then write tests (per CONTRIBUTING.md) and try to merge it.
Since I was not able to advance #303 recently, I propose this goes ahead, and we coordinate that it has #303 in mind to keep consistency in naming and meanings.