Would like a precise way to map PerformanceTimings to FetchEvent

From https://github.com/w3c/ServiceWorker/issues/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()

Start by reviewing the issue and its linked ServiceWorker issue, then examine how PerformanceTimings, FetchEvent, clients, and navigation preload are related in the current specification. Done requires an agreed API design that exactly links each timing to its originating FetchEvent or client, including repeated URLs and concurrent loads.