- From: Ilya Grigorik <igrigorik@google.com>
- Date: Thu, 8 Jan 2015 11:23:47 -0800
- To: "Schurman, Eric" <ericsc@amazon.com>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
Received on Thursday, 8 January 2015 19:24:54 UTC
On Tue, Jan 6, 2015 at 11:59 AM, Schurman, Eric <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" -> "example.com/en-us" redirect for a navigation request, the result would be: performance.getEntriesByType("navigation") -> [ PerformanceEntry{name: "example.com", <timing attrs>}, PerformanceEntry{name: "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
Received on Thursday, 8 January 2015 19:24:54 UTC