W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2015

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

From: Schurman, Eric <ericsc@amazon.com>
Date: Thu, 8 Jan 2015 21:12:39 +0000
To: Ilya Grigorik <igrigorik@google.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <FE0A6945A7351D438EE7980DE2A09DC951F03E6A@ex10-mbx-36003.ant.amazon.com>
That sounds great. It would provide better granularity and attribution.
That could also help track down cases where you have chains of redirects.

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>


Received on Thursday, 8 January 2015 21:13:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 January 2015 21:13:04 UTC