resource-timing
resource-timing copied to clipboard
w3c
RT should handle multi-request fetches
Discussion: https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0059.html
I think having redirects as their own resource entries is doable, now that FETCH and RT are integrated.
I suggest giving them redirect as an initiatorType, have them totally not exposed when the overall FETCH is cross-origin and fails TAO (or navigation timing with cross-origin redirects), and add a property such as originalURL that points to the first URL of a request.
preflights in the context of TAO-enabled cross-origin is a bit tricky, I'm not sure that when TAO is enabled it means that the 3rd party domain is OK with exposing the detail of how long in took to perform the preflight.
Note also the discussion in https://github.com/w3c/resource-timing/issues/223.
When we add more "TAO-protected" information to resource timing entries, we retroactively change the meaning of existing uses of TAO headers.
I believe that at least as a first step, this information should be only available for same-origin, regardless of TAO, until some versioning scheme or some other solution is found for "TAO yesterday and TAO today mean two different things".
A use-case I have come across for recording multi-request fetches would be to allow you to access the server-timing headers from the previous navigation in a redirect chain.
--- Example ---
If when when navigating to a URL, https://example.com/doSomething I get the following response headers:
Response
HTTP/1.1 302
location: /results
server-timing: foo; dur=100
The browser will redirect to https://example.com/results but the server-timing header sent in the initial response is lost.
performance.getEntriesByType("navigation") should allow a means to access the serverTiming array for the redirect navigation. Currently this is not possible as only the last request in the sequence is available on NT.
