This came up in the context of a Lighthouse run on WPT (wpt) with 100% for the perf category but failing the load-fast-enough-for-pwa audit. This page loads a very large JS payload, then does client detection and redirects mobile browsers to a very lightweight "unsupported" page.

It turns out with throttling of both devtools and provided (with WPT's throttling), this site has a TTI of 0.6s because in those modes we measure from the last navStart (the redirect to the "unsupported" page) to TTI, not the initial navigation. simulated throttling measures from the first document request, so shows a slow TTI for the page (this is why the WPT result shows both a fast and slow TTI, because load-fast-enough-for-pwa uses lantern TTI if throttling is provided)

There are a few things happening here that need to be handled:

• we don't track JS redirects with our finalUrl system. This means that the LH report doesn't reflect the actual URL you end up on, you don't get audit warnings to try out the finalUrl instead of the requestedUrl because the redirect could have been affecting your results, you don't get redirect info in the redirects opportunity, etc

  The network protocol messages don't include JS redirect info, so we'll have to look elsewhere for the signal. Initiator info does look correct, however.

• Be consistent on a starting point for metrics and timestamps. Currently for devtools and provided we use the last navStart with our frame ID (which in this case is the "unsupported" page), but for lantern we use the the first document requested (for this case the initial heavyweight page that redirects to the "unsupported" one).

  We include redirect information in an opportunity, but we non-lantern tries to measure the last page load. We should make a decision if we want to include these sometimes super-slow redirects against the perf metrics. Basically, are these perf metrics for requestedUrl or for finalUrl (assuming we fix finalUrl to account for JS redirects)?

• Need to split NetworkAnalyzer.findMainDocument into two methods (or something like that) :) All the lantern stuff uses it without finalUrl, at which point it looks for the first document request in the network records. If you do pass it a finalUrl, however, it finds the finalUrl document even though it's ostensibly the last document request (in this particular case it works out to the same thing, but in the case of server redirects, lantern metrics and audits relying on the main-resource computed artifact will have different main resources)