fix(trace): Prefer standalone span indicators over pageload span indicators#110297
Open
nsdeschenes wants to merge 3 commits intomasterfrom
Open
fix(trace): Prefer standalone span indicators over pageload span indicators#110297nsdeschenes wants to merge 3 commits intomasterfrom
nsdeschenes wants to merge 3 commits intomasterfrom
Conversation
…cators When both a pageload span and a standalone LCP span exist in a trace, the indicator was incorrectly placed using the pageload span's timing. Standalone spans (ui.webvital.*) have precise timing at their start_timestamp, so their indicators should take priority over indicators from pageload spans that use start_timestamp + measurement offset. Refs EXP-824 Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com> Made-with: Cursor
Verify that when a pageload span and a standalone ui.webvital.lcp span both have LCP measurements, only the standalone span's indicator is used with its precise start_timestamp. Refs EXP-824 Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com> Made-with: Cursor
github-actions
bot
added
the
Scope: Frontend
Contributor
Author
|
@sentry review |
Contributor
Author
|
@cursor review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Standalone LCP spans should still apply their measurement offset even when the trace waterfall uses the trace time origin as the timestamp base. This updates the indicator calculation and adds coverage for both span-start and trace-origin paths. Refs EXP-824 Co-Authored-By: GPT-5.4 <noreply@openai.com> Made-with: Cursor
edwardgou-sentry
approved these changes
Mar 10, 2026
Lms24
approved these changes
Mar 10, 2026
Member
There was a problem hiding this comment.
Thanks for fixing! I have to admit I'm a bit surprised that this happens because the SDK should only send either an LCP measurement on the pageload span, or a standalone LCP span. Never both. Same for CLS. Do you have a link to a trace where both are sent? This sounds like an SDK bug we should fix.
Comment on lines
+836
to
+837
| children: [ | ||
| makeEAPSpan({ |
Member
There was a problem hiding this comment.
standalone LCP spans aren't children of the pageload span. They're siblings. Not sure if we can model this in the test. Just wanted to call it out
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Fix trend line placement for standalone LCP spans in the trace waterfall.
When both a pageload span and a standalone LCP span are present, the trace
waterfall should prefer the standalone span's indicator instead of leaving the
pageload-derived indicator in place.
This branch now does two things. First, standalone span measurements replace an
existing indicator of the same type so the more specific LCP span wins.
Second, the indicator timestamp still applies the measurement offset from the
provided origin rather than assuming standalone spans always occur exactly at
span start. That matters for both the node-start path and the
performance.timeOriginpath used by EAP trace data.The updated tests cover standalone indicator priority and the trace-origin case
so we don't regress the offset calculation again.
Refs EXP-824