Measure relative to fetchStart?

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.

[deasems]

Thanks for the guidance @philipwalton

[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).