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

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

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 8 Jan 2015 11:23:47 -0800
Message-ID: <CADXXVKpq8iBa0Vr=QsGxbz-wn+R_J8apo9CQvQU6AGg6q29P4A@mail.gmail.com>
To: "Schurman, Eric" <ericsc@amazon.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
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

This archive was generated by hypermail 2.3.1 : Thursday, 8 January 2015 19:24:55 UTC