Faster TTFB than LCP

[bcoe]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• 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/browser

SDK Version

8.18

Framework Version

No response

Link to Sentry event

No response

SDK Setup/Reproduction Example

@sentry/react@8.18.0
│ ├─┬ @sentry/browser@8.18.0
│ │ ├─┬ 
[@sentry](https://x.com/sentry)
-internal/browser-utils@8.18.0
│ │ │ ├── @sentry/core@8.18.0 deduped
│ │ │ ├── @sentry/types@8.18.0 deduped
│ │ │ └── @sentry/utils@8.18.0 deduped
│ │ ├─┬ 
[@sentry](https://x.com/sentry)
-internal/feedback@8.18.0
│ │ │ ├── @sentry/core@8.18.0 deduped
│ │ │ ├── @sentry/types@8.18.0 deduped
│ │ │ └── @sentry/utils@8.18.0 deduped
│ │ ├─┬ 
[@sentry](https://x.com/sentry)
-internal/replay-canvas@8.18.0
│ │ │ ├── 
[@sentry](https://x.com/sentry)
-internal/replay@8.18.0 deduped
│ │ │ ├── @sentry/core@8.18.0 deduped
│ │ │ ├── @sentry/types@8.18.0 deduped
│ │ │ └── @sentry/utils@8.18.0 deduped
│ │ ├─┬ 
[@sentry](https://x.com/sentry)
-internal/replay@8.18.0
│ │ │ ├── 
[@sentry](https://x.com/sentry)
-internal/browser-utils@8.18.0 deduped
│ │ │ ├── @sentry/core@8.18.0 deduped
│ │ │ ├── @sentry/types@8.18.0 deduped
│ │ │ └── @sentry/utils@8.18.0 deduped
│ │ ├── @sentry/core@8.18.0 deduped
│ │ ├── @sentry/types@8.18.0 deduped
│ │ └── @sentry/utils@8.18.0 deduped
│ ├─┬ @sentry/core@8.18.0
│ │ ├── @sentry/types@8.18.0 deduped
│ │ └── @sentry/utils@8.18.0 deduped
│ ├── @sentry/types@8.18.0
│ ├─┬ @sentry/utils@8.18.0
│ │ └── @sentry/types@8.18.0 deduped

Steps to Reproduce

A user reported a faster TTFB measurement than LCP and found this to be odd (how did we render the LCP faster than delivering the first byte of data to the customer?)

@k-fish suggested maybe this has to do with prefetching resources? If so, could we detect this and indicate it in the UI?

Expected Result

LCP happen some time after TTFB.

Actual Result

LCP is faster than TTFB.

Internal Tracking: https://www.notion.so/sentry/GH-13040-Faster-TTFB-than-LCP-4f01c7a5ce8949f0a3b7b7ea37bb129a?pvs=4

[Lms24]

I'm fairly sure, I found the root cause of what's causing this incorrect behaviour:

We normalize LCP/FCP/FP values in a very weird way in the SDK, where it looks like we try to re-calculate LCP from the beginning of the pageload transaction. I think the reason for this is that we need to draw the vertical line for LCP in the trace view but there are a couple of fundamental problems:

• Before our normalization logic, the LCP value we'd send is perfectly aligned with the raw value from the PerformanceObserver and the web-vitals chrome extension. So at some point we actually collect the correct one.
• I understand that we might need to shift the value somewhat to align it properly in the trace view (actually, do we really need to?) but for this we cannot change the measured LCP value itself
• From what I could reproduce and observe, it looks like we always decrease the LCP value, which correlates well with the reports in Web Vitals are captured incorrectly #13006.
  • Example: Before normalization, we measure TTFB 10ms, LCP/FCP 180m. After normalization: TTFB 10ms, LCP/FCP 2ms. This is completely incorrect.

I will check what removing the LCP/FCP/FP value normalization does to the values shown in the Sentry UI. My hunch is that they'll be much more accurate. We need to check the impact on the trace view especially though.