FCP higher than LCP on individual page loads

[serglom21]

Is there an existing issue for this?

• [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [x] I have reviewed the documentation https://docs.sentry.io/
• [x] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/remix

SDK Version

8.25.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

Customer Case

On individual events of page loads for Remix, I am seeing that the measurement for FCP is higher than LCP in some cases It seems that a similar issue was reported on previous versions of the SDK but that was closed since it seems that v7 fixed it. But we are seeing the same discrepancy in v8

Expected Result

I would expect FCP to always be lower than LCP

Actual Result

FCP is higher than LCP in some cases

[Lms24]

backlogging to triage after hackweek

[Lms24]

So this is still a bit concerning as I haven't yet found a reason as to why it would happen consistently. Some notes:

• Based on my understanding of LCP, it should never be lower than FCP. It might be equal to - whenever there LCP element happend in the same paint as FCP - but never lower.
• We do have some LCP value "normalization" logic, which I'm gonna experiment with removing but the same logic also applies to F(C)P. So theoretically, this code path should mess up both values equally but not reduce one more than the other one 😅. But maybe I'm missing something and removing this logic solves it too.
• There are cases when LCP is reported lower by the SDK than by web vitals. Specifically, this is expected when a new LCP element is rendered after the pageload span finishes. The fix for this is https://github.com/getsentry/sentry-javascript/issues/13063

[crazyones110]

I encountered the same issue, maybe it's because the largest contentful paint element is a cross-origin resource which doesn't set the TIMING-ALLOW-ORIGIN header. MDN link Perhaps we can add a flag to indicate if it's an accurate LCP

const isAccurateLCP = entry.renderTime ? true : false;

[mydea]

Hey, we have looked some more into this, and yes, we also believe it may be because of the missing Timing-Allow-Origin header. cc @bcoe and @Lms24 we are looking into how we can possibly surface this better!

[bcoe]

See related tracking ticket https://github.com/getsentry/sentry/issues/80747

[mydea]

@Lms24 I believe there was some change around this header in Chrome recently, is this still an issue?

[Lms24]

Yup, more recent browsers now provide a still coarse but non-zero render time without Timing-Allow-Origin headers.

From MDN:

Browsers may now expose a slightly coarsened render time in these situations. Check for browser support.

With the recent fixes and browser improvements I think it's fair to close this issue for now.