When response comes from a worker, some of the timing-info should pass through

[noamr]

Right now when the response comes from a worker, it comes with timing info, however FETCH later overrides the timing info with the timing info of the fetch, which would lose some information. Some of the info such as the connection info should come from the pass-through response, while other information such as the start time should come from the original request.

[annevk]

This looks reasonable to me. One tricky aspect might be the time coarsening. If the SW has the capability but we don't, we need to coarsen the SW times here. Otherwise they can be kept as-is.

(That would be in line with what I suggested at w3c/ServiceWorker#1575 (comment) so if that changes we'd need to adjust for that here too.)

[noamr]

OK the problem here is that in the case of service workers, there could be two fetches with one response. One fetch is the original fetch from the document, and the other one is the potential fetch() call inside the service worker, which forwards its response to the original fetch. A resource timing entry corresponds to a fetch, rather to a response, so associating it with a response could lead to some confusion.

The timing info of the internal fetch is available in the performance timeline of the service worker itself, so that information is not lost (though maybe it's a bit cumbersome to connect the dots between the two entries).

It should probably be clearer in the spec, that when a response comes from a service worker, it's something like a clone of the response, or some similar construct, and that attaching the timing info to the response is only applicable for this instance of fetch, i.e., attaching fetch timing info to the response in the document fetch does not alter the fetch timing info accessible from within the service worker.

Perhaps also a test to that effect could clarify things.

[noamr]

/cc @yoavweiss

[noamr]

As decided in the WG meeting, the info from the SW would remain opaque, but accessible from inside the service worker's performance timeline. The RT entry would stand for a particular fetch rather than a response.
This work is the first step to make this explicit.