Sites with redirects have wonky stats

[patrickhulce]

I was puzzling over some recent metrics on a plots run of http://www.vkontakte.ru/ which reported traceEnd as 5s shorter than the length of the trace. This is because we take our stats relative to navstart which removes the time of the initial HTTP request, it seems we have inconsistent handling somewhere though because TTCI failed even though there is 5s of quiet.

Example Screenshot

[patrickhulce]

Even more disturbing finding: traceviewer model does not give us timestamps that are relative to navstart but instead relative to TracingStartedInPage! This throws off all our timings and timestamps that use the traceviewer model, another great reason to get rid of it :)

[tdresser]

@deepanjanroy @benshayden

[patrickhulce]

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=725301

LH-specific issues: We need to have consistent interpretation of task start/end timestamps by either remapping the times received from traceviewer model or remove it entirely and parse the trace ourselves

Overall metric questions: Which navstart in the trace is correct? window.performance identifies the beginning of the first request (the one that gets redirected) as startTime and the beginning of the final page request as requestStart. I'm inclined to prefer this interpretation as well so that sites with many potentially unnecessary redirects are penalized appropriately.

Supposedly there are cases though where the first navstart is not particularly interesting or plain wrong which is why LH looked for the last one? cc: @paulirish

[patrickhulce]

The switch to use the last navstart occurred here in response to tracingStartedInPage being after navStart and to move in alignment with traceviewer, though I believe we could still use the first navstart but just use the frameId from tracingStartedInPage

[deepanjanroy]

Since lighthouse usually takes in a url, and gives back some metrics on that url, I think it makes sense to include the time for redirects. If I want to know the stats for http://example.com, I care about the total time from when I click the link to when key user events happen.

For traceviewer/chrome internal metrics, the story may be different - we'll have to think more about what makes sense.

[wardpeet]

going to link #2235 to this issue

[brendankenny]

The switch to use the last navstart occurred here in response to tracingStartedInPage being after navStart and to move in alignment with traceviewer, though I believe we could still use the first navstart but just use the frameId from tracingStartedInPage

was there resolution on this? I don't remember the reasoning

[paulirish]

Lantern doesn't consider navStart, but essentially uses start of HTML request as the time origin for stats. This likely leads to reduced variance, but some would argue the accuracy and/or truthiness is compromised.

[patrickhulce]

To clarify, Lantern uses the start of the very first request observed (which is when most people seem to think navstart should be), not the start of the HTML request, and it is navStart approach that reduces the variance at the expense of accuracy/truthiness by ignoring the time spent on certain cross-origin redirects.

See the above trace screenshots for the example where the time spent in the http://www.vkontakte.ru/ request is ignored from all of our metric user timings.

[patrickhulce]

This is a duplicate of #8984 which is currently in progress.