Add unique identifier to "PerformanceResourceTiming" API #1007
Conversation
|
Thanks for working on this! I'm a bit confused about how the solution (specifically option 1) maps to the use case. This OP alludes to that but this explainer doesn't... Another issue with this is that mapping a response to a |
monica-ch
changed the title
|
|
||
| ## Use Cases | ||
| Tracking resource timing across multiple requests, whether from different browsing contexts (e.g. multiple tabs) or service workers, can be challenging. Some examples include: | ||
| 1. **Measuring Resource Timing Across Client and Service Worker** <br> |
There was a problem hiding this comment.
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?
| event.respondWith((async () => { | ||
| const response = await fetch(event.request); | ||
| const entries = self.performance.getEntriesByType("resource"); | ||
| const timing = entries.find(e => e.responseId === response.responseId); |
There was a problem hiding this comment.
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); There was a problem hiding this comment.
I think getEntryById might be confusing, at least for the current explainer - as there are quite a few different kinds of Ids mentioned. Will keep the current sample code for now.
| |Distinguish between identical requests from different clients. | ✅ |✅ | ✅ | | ||
| |Enables end-to-end correlation between requests, responses, and resource timings.| ❌ |✅| ❌ | | ||
| |Leverages existing identifiers (FetchEvent).| ❌ | ❌ | ✅ | | ||
| |Developers do not need to generate and manage RequestIds | ✅ |❌| ✅ | |
There was a problem hiding this comment.
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?
Co-authored-by: David Risney <dave@deletethis.net>
Co-authored-by: David Risney <dave@deletethis.net>
Co-authored-by: David Risney <dave@deletethis.net>
|
@david-risney I have mostly addressed the comments. Do take a look |
Explainer doc for the feedback.