fix(web-vitals): Adjust some web vitals to be relative to fetchStart and some other improvements

[dashed]

Some Web Vitals that are based on timings, specifically FCP, FP, LCP, and TTFB are measured relative to timeOrigin (https://www.w3.org/TR/hr-time-2/#dfn-time-origin). Unfortunately, this conflicts with the generated span data sourced from the level 2 Navigation Timings as captured from the JS SDK (https://www.w3.org/TR/navigation-timing-2/).

As an example:

One approach would be to measure relative to other timings such as fetchStart. See: GoogleChrome/web-vitals#19

Intuitively, it's more practical to adjust some web vitals to be relative to the starting point of the transaction.

---

This PR addresses the following:

1. Create a span that measures from fetchStart to domainLookupStart. This adds more completeness to the processing model. By creating this span, this will usually adjust transaction.startTimestamp for some pageload transactions.

See: https://www.w3.org/TR/navigation-timing-2/#processing-model

What it looks like:

2. Adjust web vitals, specifically FCP, FP, LCP, and TTFB, to be relative to transaction.startTimestamp. This makes an assumption that transaction.startTimestamp is the earliest known starting point.

What the adjustment looks like with debug: true:

3. Create FID span which gives visualization of when the user clicks on the page, up to the time that the click was processed by JS event loop handler.

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	19.68 KB (+0.01% 🔺)
@sentry/browser - Webpack	20.54 KB (0%)
@sentry/react - Webpack	20.54 KB (0%)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	26.83 KB (+0.63% 🔺)

[markstory]

Should this be 'vitals' to match the more generic name we'll likely use in the future?

[dashed]

Right now we've not committed to using that term as a generic umbrella.

We've only used "web vitals" thus far.

[lobsterkatie]

Is the fact that the op is currently two words going to mean that when searching for it, you have to put it in quotes? (I would guess that the answer is yes.) If so, can we make this one word (even if it's webVitals or web.vitals or webvitals) so that users don't have to do that?

[dashed]

web.vitals works 👍

[lobsterkatie]

After talking this over with @dashed , this makes good sense to me. By adding in a fetchStart span, we'll be starting the transaction at the earliest possible moment in all cases, meaning the only blocks we could ever potentially "miss" ("Prompt for Unload" and "Redirect" in the diagram above) are ones which either don't exist (redirect) or aren't relevant to our users (unload).

[dashed]

@Zylphrex feel free to push commits to this branch as you see fit.

[eightHundreds]

Adjust web vitals, specifically FCP, FP, LCP, and TTFB, to be relative to transaction.startTimestamp. This makes an assumption that transaction.startTimestamp is the earliest known starting point.

@dashed

why relative to transaction.startTimestamp instead of fetchStart.
transaction.startTimestamp is performace.timeOrigin+performace.now().

[AbhiPrasad]

@eightHundreds

The startTimestamp of a transaction gets adjusted when we add browser related spans. As such, making the web-vitals relative to the startTimestamp value should produce the most accurate value.

[Dante-dan]

we add browser related spans.

It is not found.

Actually, I am seeing significant differences between the data(LCP/FCP) I am getting from Sentry and what I am getting from Google Search Console. I don't know what to do in the above situation.

[AbhiPrasad]

@Dante-dan found here now:

sentry-javascript/packages/tracing/src/browser/metrics/index.ts

Line 168 in 2bdda84

_addResourceSpans(transaction, entry, resourceName, startTime, duration, timeOrigin);

Actually, I am seeing significant differences between the data(LCP/FCP) I am getting from Sentry and what I am getting from Google Search Console. I don't know what to do in the above situation.

Under the hood we use Google's web vitals library to grab LCP/FCP data. This is what the web vitals team themselves recommend:

sentry-javascript/packages/tracing/src/browser/web-vitals/getLCP.ts

Line 33 in f8047f6

export const onLCP = (onReport: ReportCallback): void => {

It is strange there is a significant difference though. @Dante-dan could you provide some kind of reproduction and open an issue on the JS SDK repo? That will help us dig in further!

[Dante-dan]

Fine, I think I have found the problem.

1. I tried scenarios where either performance.timeOrigin or performance.timing.navigationStart API do not exist, and in debug mode, the FCP values have minor discrepancies.
2. I found the count of pageload and the count of LCP on Sentry, they're significant differences. Because the measurements are only available for pageload transactions. This means that only the earlier LCPs are reported with pageload, while the slower LCPs often occur after pageload, resulting in much smaller LCPs being collected than what Google reports.