Measure relative to fetchStart? about web-vitals HOT 7 CLOSED

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

from web-vitals.

Thanks for the guidance @philipwalton

from web-vitals.

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.

from web-vitals.

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(...)
  ...
});

from web-vitals.

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

from web-vitals.

@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

from web-vitals.

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.

from web-vitals.