All redirects cause loss of critical data from Performance.Timing

If there are any redirects involved, information about DNS lookups and TCP connections is lost which makes it difficult to track problems. If there is no redirect, then connectStart/End and domainLookupStart/End are accurate. But if there is a redirect (even same origin), then these all get reset to fetchStart for the final GET (as per the interactions of Rule 16, 7, and 11 in the processing model).

As an example, imagine that a request to http://www.example.com/ results in a redirect to http://www.example.com/en-us/. This site would get zero useful information about connection, dns lookups, etc. for these hits - which are a major source of where traffic enters the site and where the DNS lookup and TCP connections need to be made. This would be true for all incoming traffic that involved a redirect     .

This can also result in aggregated metrics that are misleading - if we look at aggregate connectEnd times, some will be when the connection ended and some when same origin redirects ended. For sites that use connectStart-connectEnd to give a connectDuration, then it looks like there was zero time spent making the connection.

As is, if we have a long time before requestStart, we can't really tell if it's caused by third party redirects, a redirect from example.com to www.example.com<http://www.example.com>, a long TCP connection time, DNS lookup times, etc. This is exactly the sort of thing we'd want to use Navigation Timing data for. navigation.redirectCount can give some information, but it's very limited.

Are there plans to address this?