RE: All redirects cause loss of critical data from Performance.Timing

That sounds great. It would provide better granularity and attribution.
That could also help track down cases where you have chains of redirects.
-Eric

From: Ilya Grigorik [mailto:igrigorik@google.com]
Sent: Thursday, January 08, 2015 11:24 AM
To: Schurman, Eric
Cc: public-web-perf@w3.org
Subject: Re: All redirects cause loss of critical data from Performance.Timing


On Tue, Jan 6, 2015 at 11:59 AM, Schurman, Eric <ericsc@amazon.com<mailto:ericsc@amazon.com>> wrote:
Are there plans to address this?

Not that I'm aware of, but I think we should. I've ran into the same problem on a number of occasions myself.

My proposal would be to treat redirect requests as standalone requests.. which is precisely what they are to begin with. For example, following your example of "example.com<http://example.com>" -> "example.com/en-us<http://example.com/en-us>" redirect for a navigation request, the result would be:

performance.getEntriesByType("navigation") -> [
   PerformanceEntry{name: "example.com<http://example.com>", <timing attrs>},
   PerformanceEntry{name: "example.com/en-us<http://example.com/en-us>", <timing attrs>}
]
performance.navigation.redirectCount --> reports 1.. as it does today.
performance.timing --> reports timing data for the *last* request in redirect chain.. as it does today.

Same logic applies for Resource Timing: each distinct URL request gets it's own PerformanceEntry.

The end result is that all existing code continues to work as is, but those interested in accounting for redirect overhead can now inspect the timeline and get the appropriate metrics.

Thoughts? </hand waving>

ig