resource-timing icon indicating copy to clipboard operation
resource-timing copied to clipboard

Expose a way to link a call to fetch to an individual PerformanceResourceTiming object

Open n8schloss opened this issue 7 years ago • 3 comments

(copy and pasting from https://github.com/whatwg/fetch/issues/491)

Problem

Currently the process of linking a fetch request to a specific resource timing object is imperfect. If there are two fetch api requests for the same resource that happen within a short time it's impossible to tell exactly which fetch call initiated which request, leading to some errors in performance logging. Orthogonally, if all a developer cares about is the perf result for a single fetch, having to use the whole performance api could be cumbersome.

Solution?

The ideal solution here (imo) is for there to be a way to get a resource timing object for a specific response. This could be accomplished by adding a method to response objects that give you a promise which will eventually resolve to the PerformanceResourceTiming object once it's ready.

Thoughs?

n8schloss avatar Feb 21 '17 23:02 n8schloss

The problem described here is just one case of aliasing of the HTTP representation that can occur by only relying on the "name" (aka URL). HTTP Content Negotiation describes some other methods that this could occur with.

One example that I am directly aware of is making multiple range requests (Using the Range header), it is impossible to differentiate. Inferring from the content length is unfeasible because range requests could request the same range size but vary by byte index.

LPardue avatar Jun 06 '17 14:06 LPardue

I'm not sure what the existing spec says when you don't consume the body, but it seems like there should be valuable timing state immediately on Response construction? Thus, a persistent reference to (what I assume is an underlying mutable) perf entry is probably equally acceptable vs needing a method to resolve. In other words, the instant a Response is created, perf entries are likely already existent. I assume that such entries shall be updated contingent on additional response behavior, such as reading the stream. I rarely think about the case where:

const res = await fetch(...)
await doSlowWork()
await res.json()

...and how that may/may-not impact the perf entries API, such as this. gotta hit the spec :glasses: 📖

Nonetheless, some link (direct ref, method to get immutable copy, whatever) seems warranted. Today I wrote a server-timing in parser in JS to chain to my fetch calls, as we do not have such a linkage natively.

cdaringe avatar Jun 04 '22 00:06 cdaringe