Measure relative to fetchStart?

[deasems]

My application is behind authentication which is handled via redirects to another domain outside my control. I've implemented logging of navigation and paint timing metrics recently and noticed the redirect time introduces significant variance in the data (depending on if a redirect for auth was needed or not).

Looking at the Navigation timing model, it also seems inappropriate to include unload time from the previous site because that is out of my app's control.

Based on this I adjusted our perf measurements to be relative to the fetchStart instead of startTime.

I wanted to get your team's input - does this seem like a reasonable thing to do for performance metrics? or am I missing some value here?

Maybe this could be added as an option to this lib.

[philipwalton]

The getTTFB() documentation addresses this issue and shows an example of how to measure things related to navigation timing—in addition to TTFB. Does that address your concern?

My recommendation would be to track TTFB (as defined here), but then also track additional metrics that you might have more control over fixing.

[deasems]

Thanks, it's helpful to see there's some precedent to adjust these measurements relative to different points in the navigation timing.

I'd want to shift values for all metrics that are measured from navigation start time (LCP, TTFB, FCP) so without support for offsets in the library I think the cleanest way would be to get the navigation timing data manually for use in the report handlers. (Using the nav timings from TTFB in other metrics seems error prone because of potential race conditions)

Edit: unless you think this pattern is viable? not sure if some of these metrics would get missed by waiting for TTFB to fire first.

getTTFB(metric => {
  const timingOffset = metric.entries[0].fetchStart;
  getFCP(fcp => {
    log(fcp.value - timingOffset);
  });
  getLCP(...)
  ...
});

[Zizzamia]

Ciao @deasems
do the redirects in your app also influence FCP and LCP?
I ask because if it is, this would be something interesting to report also with the W3C Performance Timeline Committee

[deasems]

@Zizzamia My understanding is that paint timings intentionally do include the the redirect time (just like the navigation timings do) because their 'time origin' is the navigation startTime

[philipwalton]

Yes, the web APIs all measure relative to the time origin, which includes unload, DNS, connection, etc.

Unless you think this pattern is viable? not sure if some of these metrics would get missed by waiting for TTFB to fire first.

getTTFB(metric => {
  const timingOffset = metric.entries[0].fetchStart;
  getFCP(fcp => {
    log(fcp.value - timingOffset);
  });
  getLCP(...)
  ...
});

That would work, though I'd strongly encourage you to at minimum track both versions of the metric, or track them separately so you could do the math on the back end but still report both values.

I'd also encourage you to call the metrics by a different name of you're going to change their definition. Otherwise it could lead to confusion if you were going to compare those scores to the scores reported by other Google tools (and keep in mind that within Chrome, these values are always measured relative to the time origin).

[philipwalton]

I'm going to close this issue as I don't think there's any additional changes that need to be made in the library or docs. Please let me know if I've missed something though, and I can reopen.

[deasems]

Thanks for the guidance @philipwalton