-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(browser): Add afterStartPageloadSpan
hook to improve spanId assignment on web vital spans
#16893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size-limit report 📦
|
f66980a
to
74a7f92
Compare
74a7f92
to
f54d641
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Web Vital Reporting Callback Timing Issue
The listenForWebVitalReportEvents
function introduces two bugs:
- The
onHidden
callback now unconditionally calls_runCollectorCallbackOnce
, which sets thecollected
flag totrue
. This can occur before thepageloadSpanId
is available, preventing thecollectorCallback
from being triggered by subsequentnavigation
events. - A ReferenceError occurs because the
unsubscribeAfterStartPageLoadSpan
variable is accessed in thebeforeStartNavigationSpan
callback before its declaration.
packages/browser-utils/src/metrics/utils.ts#L220-L237
sentry-javascript/packages/browser-utils/src/metrics/utils.ts
Lines 220 to 237 in f54d641
onHidden(() => { | |
_runCollectorCallbackOnce('pagehide'); | |
}); | |
const unsubscribeStartNavigation = client.on('beforeStartNavigationSpan', (_, options) => { | |
// we only want to collect LCP if we actually navigate. Redirects should be ignored. | |
if (!options?.isRedirect) { | |
_runCollectorCallbackOnce('navigation'); | |
unsubscribeStartNavigation?.(); | |
unsubscribeAfterStartPageLoadSpan?.(); | |
} | |
}); | |
const unsubscribeAfterStartPageLoadSpan = client.on('afterStartPageLoadSpan', span => { | |
pageloadSpanId = span.spanContext().spanId; | |
unsubscribeAfterStartPageLoadSpan?.(); | |
}); |
Was this report helpful? Give feedback by reacting with 👍 or 👎
AbhiPrasad
approved these changes
Jul 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our standalone web vital spans need to include the span id of the
pageload
span s.t. we can correctly assign the web vital value to the respective pageload span in the Sentry backend.In the previous implementation, we'd simply wait for a tick after tracking the web vitals, get the active root span and take its spanId if it was a pageload span. However, this relies on the assumption that the pageload span is indeed started immediately. By default this happens but users can always deactivate default behaviour and call
startBrowserTracingPageloadSpan
whenever they want (for example, in a custombrowserTracingIntegration
).Furthermore, this "wait for a tick" logic always bugged me and was only done because
getClient()
would not yet return the already initialized client.This PR now makes the pageload spanId retrieval more robust by
afterStartPageloadSpan
. This callback fires as soon as the pageload span is actually started and available.client
from thebrowserTracingIntegration
'ssetup
hook into the web vital listening function so that we can remove thesetTimeout(_, 0)
logic.