Would like a precise way to map PerformanceTimings to FetchEvent

[jakearchibald]

From w3c/ServiceWorker#1179 by @clayw

ServiceWorkerGlobalScope.performance.getEntries() gives me all of the performance timing data that's gone through the service worker, but there's no exact mapping back to the original FetchEvent or client to which they originated. Multiple FetchEvents can have the same URL and thus the same PerformanceEntry.name field, for example.

Some strategies for dealing with this may be to look at the sequencing of when they come in or mapping the actual timings back to the event. But it seems like it shouldn't be necessary to try and do any complicated guesswork, especially if there may be some edge cases (eg, loading two tabs simultaneously, quirks with navigation preload, etc).

Can there be some way to exactly link these via API? For example:

• WorkerPerformance.getEntriesByClientId(clientId) call to filter by client ids
• Adding a clientId field into the PerformanceResourceTiming somehow
• Some sort of thenable from FetchEvent like FetchEvent.getResourceTimings()

[jakearchibald]

Adding a clientId field into the PerformanceResourceTiming somehow

Sounds like the simplest and right answer to me.

[yoavweiss]

A unique identifier in PerformanceResourceTiming would be beneficial for other purposes as well. By clientId do you mean https://fetch.spec.whatwg.org/#concept-request-target-client-id?

[jakearchibald]

The OP talks about the originating client, so that maps more to https://fetch.spec.whatwg.org/#concept-request-client.

[yoavweiss]

IIUC that means all the resource entries (or at least all the ones triggered by window) would have a similar ID (as they all share an environment settings object). Might be better to add a unique ID to the Request itself.

[jakearchibald]

Hmm, yeah, given getEntries only returns fetches from this global, the data would reflect fetches the service worker made, not fetches that were made to the service worker. Hmm.

[clayw]

The client id that I'm referring to is this: https://developer.mozilla.org/en-US/docs/Web/API/Client/id

There are other quirks the performance timeline APIs with serviceworkers that Jake may be alluding to in the comment above. Some of the timings from the window POV and serviceworker POV become different (such as responseStart/End may refer to timings of cache fetches). I think it makes sense the way it is, but a bit weird that the same API has these quirks in the different contexts that they are in. May be good to extend the diagram in the spec to show how timings may be different between the two views: https://www.w3.org/TR/resource-timing-1/#processing-model

[igrigorik]

Can there be some way to exactly link these via API? For example:

WorkerPerformance.getEntriesByClientId(clientId) call to filter by client ids
Adding a clientId field into the PerformanceResourceTiming somehow
Some sort of thenable from FetchEvent like FetchEvent.getResourceTimings()

I'd love to see all of the above. We need a simple way to map RT objects to Fetch#Response, and vice versa, make it easy to access RT data from the Fetch#Response.

SW's client ID doesn't seem the right fit though.. we need this to work both in Worker and Window contexts. Would it make sense to generate some unique id on Fetch#Response, which we could then expose on RT entry?

Also, we should consider if/how #21 can be addressed in this context.

/cc @annevk

[annevk]

I think it would help a lot if someone first described the actual model that underpins RT objects. Currently if you read through Fetch it's entirely unclear how RT objects end up getting allocated and where they exist.

Once that's clear (and someone verified it reasonably maps to implementations) it would be easier to come up with a good API.

[clayw]

Has there been any progress on this?

[yoavweiss]

@jakearchibald is this only relevant for Resource/Navigation Timing, right? If so, might be best to move this issue to the RT repo

[marcelduran]

Any progress on this?

@yoavweiss I believe this is only relevant to RT if we agree on exposing an unique id on RT entries.

The question is what this unique id will look like. @clayw's described use case for SW would set the same client.id for all RT entries originated from a SW client. In this case, querying RT entries by a given id should be trivial (e.g.: getEntriesById(client.id)).

If every Fetch#Response automatically generates its own unique id, then some manual mapping will still be needed and has to be maintained. For the SW use case, the mapping would be SW client.id --> Fetch#Response unique ids.

If instead of automatically generating an unique id, such id could be arbitrarily set via Fetch then it's up to the developer what to set it to. In @clayw's use case, it could be SW client.id. I'm afraid that would require some changes on the Fetch API too.

[npm1]

This seems the same as #255, except the solution proposed there is the inverse mapping.

[annevk]

Yeah, this seems to be a problem that exists outside service workers as well. If you fetched /x multiple times or some such you'd have to keep track of order yourself.