Add unique identifier to "PerformanceResourceTiming" API

[monica-ch]

Explainer doc for the feedback.

[noamr]

Thanks for working on this! I'm a bit confused about how the solution (specifically option 1) maps to the use case.
Seems like the use case is about mapping resource timing entries to fetch events, but the solution in option 1 only deals with navigations and maps the clientId, which would be the same across resources?

This OP alludes to that but this explainer doesn't...

Another issue with this is that mapping a response to a clientId only works if you don't use caches, which often beats the purpose of using a service-worker in the first place. A Cache allows you to reuse responses across clients, and this kind of mapping would break on the first response reuse.

[fabiorocha]

Looks like both files are almost identical. I assume we only need one of them?

[david-risney]

Please replace smart quotes with regular quotes.

Suggested change

	requestId: “123e4567-e89b-12d3-a456-426614174000”
	requestId: "123e4567-e89b-12d3-a456-426614174000"

[david-risney]

Please fix smart quotes

Suggested change

	method: ‘GET’,
	method: 'GET',

[david-risney]

Suggested change

[Resource Timing](https://www.w3.org/TR/resource-timing/) API has no information that uniquely identifies each resource timing to each fetch request. As such, in situations where resources are fetched multiple times, such as with multiple tabs or multiple requests to the same URL, it’s not possible to accurately map resource timings. This lack of clear mapping can hinder performance analysis and optimization efforts.

The [Resource Timing](https://www.w3.org/TR/resource-timing/) API has no information that uniquely maps each resource timing to each fetch request. As such, in situations where resources are fetched multiple times, such as with multiple tabs or multiple requests to the same URL, it’s not possible to accurately map resource timings. This lack of clear mapping can hinder performance analysis and optimization efforts.

[david-risney]

This <br> and the next <br> look weirdly out of place as the only embedded HTML in the document. Can you replace with an additional newline?

[david-risney]

Suggested change

When multiple tabs request the same resource through a service worker, associating timing data between the Performance Resource Timing entries observed in the client and those within the service worker can be difficult. The client-side performance.getEntries() provide the total duration of the request, but it lacks insight into processes inside service worker, such as request handling and network retrieval. The service worker itself can collect performance timing for fetch requests, but there is no direct linkage between these entries and those in the client’s performance timeline.

When multiple tabs request the same resource through a service worker, associating timing data between the Performance Resource Timing entries observed in the client and those within the service worker can be difficult. The client-side `performance.getEntries()` provides the total duration of the request, but it lacks insight into processes inside the service worker, such as request handling and network retrieval. The service worker itself can collect performance timing for fetch requests, but there is no direct linkage between these entries and those in the client’s performance timeline.

[david-risney]

All of the sample code in this document contains code something like this

      const entries = self.performance.getEntriesByType("resource"); 
      const timing = entries.find(e => e.responseId === response.responseId); 

Should we also be proposing a new Performance function to help find these entries?

partial interface Performance {
  PerformanceEntry getEntryById (DOMString id);
}

      const timing = self.performance.getEntryById(response.responseId); 

[david-risney]

Suggested change

	[ Exposed=Window, Worker ]
	[Exposed=(Window,Worker)]

[david-risney]

Suggested change

	console.log(request.requestId); '123e4567-e89b-12d3-a456-426614174000'
	console.log(request.requestId); // '123e4567-e89b-12d3-a456-426614174000'

[david-risney]

Suggested change

	[ Exposed=Window, Worker ]
	[Exposed=(Window, Worker)]

[david-risney]

For option 2 I thought the request ID is optional and will be generated by the user agent if not provided? If so then 'Developers do not need to generate manage RequestIds' for option 2 is true - they don't need to. Maybe this row is supposed to be about removing flexibility for end devs to use their own IDs?

[fabiorocha]

LGTM after pending comments are addressed.