FCP regression from ~442ms to ~1460ms after upgrading @sentry/react from 8.27.0 to 8.28.0

[oekomar]

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/react

SDK Version

8.28.0

Framework Version

Preact 10.27.3, React Router v6

Link to Sentry event

No response

Reproduction Example/SDK Setup

Sentry.init({
dsn: sentryDSN,
release: rooster-webapp@${version},
environment: env,
ignoreErrors: [ /* ... / ],
allowUrls: [ / ... / ],
denyUrls: [ / ... / ],
integrations: [
Sentry.browserTracingIntegration(),
Sentry.thirdPartyErrorFilterIntegration({
filterKeys: [SENTRY_APPLICATION_KEY],
behaviour: 'drop-error-if-contains-third-party-frames',
}),
Sentry.breadcrumbsIntegration({ dom: true }),
],
tracesSampler: samplingContext => { / ... / },
beforeSend(event, hint) { / ... */ },
});

Steps to Reproduce

FCP regression from ~442ms to ~1460ms after upgrading @sentry/react from 8.27.0 to 8.28.0

Expected Result

FCP remains comparable to 8.27.0 (~442ms)

Actual Result

FCP increased to ~1460ms (~3x regression) after upgrading to 8.28.0

Additional Context

No response

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-2260

[isaacs]

Thanks for reporting this.

It looks like this might simply be a known fix to an under-reported value.

#13502 (merged 2024-08-30) removed logic in packages/browser-utils/src/metrics/browserMetrics.ts that previously adjusted FCP/LCP/FP measurements relative to the transaction start timestamp rather than reporting the raw browser-measured value. This adjustment was originally added to align web-vital vertical lines in Sentry's trace view, but it caused the reported metric values to be systematically smaller than what the browser actually measured.

After 8.28.0, _measurements['fcp'] is set directly to entry.startTime (the raw value from the browser's PerformanceObserver), which is the correct behavior. The FCP of ~1460ms is the true value; ~442ms was an SDK artifact.

The 8.28.0 release notes explicitly called this out:

"When updating your SDK to this version, you might experience an increase in LCP, FCP and FP values... the previously reported values were smaller than the actually measured values."

To verify that this is what's going on, you can independently verify the actual FCP using browser DevTools (Chrome DevTools Performance panel or Lighthouse). That should match the ~1460ms now reported by Sentry, confirming the SDK was previously underreporting. If it does not, then please share a reproduction here, and we'll be happy to re-open and investigate :)