feat(browser): Add ElementTiming instrumentation and spans#16589
Merged
feat(browser): Add ElementTiming instrumentation and spans#16589
Conversation
7680005 to
5379c13
Compare
Contributor
size-limit report 📦
|
AbhiPrasad
reviewed
Jun 16, 2025
| // - `renderTime` if available (available for all entries, except 3rd party images, but these should be covered by `loadTime`, 0 otherwise) | ||
| // - `timestampInSeconds()` as a safeguard | ||
| // see https://developer.mozilla.org/en-US/docs/Web/API/PerformanceElementTiming/renderTime#cross-origin_image_render_time | ||
| const { spanStartTime, spanStartTimeSource } = loadTime |
Contributor
There was a problem hiding this comment.
this can be a helper or return tuples, will help reduce bundle size of spanStartTime and spanStartTimeSource being un-minifiable.
Comment on lines
81
to
83
| const activeSpan = getActiveSpan(); | ||
| const rootSpan = activeSpan ? getRootSpan(activeSpan) : undefined; | ||
| const route = rootSpan ? spanToJSON(rootSpan).description : getCurrentScope().getScopeData().transactionName; |
Contributor
There was a problem hiding this comment.
we can move these outside of the loop to avoid having to keep calling spanToJSON
s1gr1d
added a commit
that referenced
this pull request
Jun 30, 2025
This PR implements sending standalone LCP spans as an opt-in feature. Behaviour-wise, it's mostly aligned with our prior implementation of sending CLS standalone spans (#13056): - add an `_experiments.enableStandaloneLcpSpans` option and treat it as opt-in - keep collecting LCP values until users soft-navigate or the page is hidden - then, send the LCP span once - adds all `lcp.*` span attributes as well as the `lcp` measurement to the span (depending on if we merge #16589 or this first, we might need to readjust size limit) closes #13063 --------- Co-authored-by: s1gr1d <[email protected]> Co-authored-by: Sigrid Huemer <[email protected]>
# Conflicts: # .size-limit.js
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Bug: ElementTiming Timing Inconsistencies
ElementTiming spans for image-paint entries have inconsistent timing due to how loadTime and renderTime are used for span start time and duration calculation, especially when one of these values is 0 (e.g., for cross-origin images without CORS). This leads to:
- Zero-duration spans starting at
loadTimewhenrenderTimeis 0 butloadTimeis present. - Spans ending at
2 * renderTimewhenloadTimeis 0 butrenderTimeis present, as duration is incorrectly calculated asrenderTime.
packages/browser-utils/src/metrics/elementTiming.ts#L71-L85
sentry-javascript/packages/browser-utils/src/metrics/elementTiming.ts
Lines 71 to 85 in f6b225c
Was this report helpful? Give feedback by reacting with 👍 or 👎
s1gr1d
approved these changes
Jul 1, 2025
This was referenced Sep 29, 2025
This was referenced Oct 7, 2025
This was referenced Oct 15, 2025
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.
This PR adds support for instrumenting and sending spans from
ElementTimingAPI entries. Just like with web vitals and long tasks/animation frames, we register aPerformanceObserverand extract spans from newly emitted ET entries.Important:
enableElementTiming: falseinbrowserTracingIntegrationnavigationspans as well). We could also go the route of only sending until the first navigation as with standalone CLS/LCP spans. Happy to accept any direction we wanna take this.Some noteworthy findings while working on this:
loadTimewhich is the relative timestamp to the browser'stimeOrigin, when the image finished loading. For text nodes,loadTimeis always0, since nothing needs to be loaded.renderTimewhich is the relative timestamp to the browser'stimeOrigin, when the node finished rendering (i.e. was painted by the browser).renderTime - loadTimefor image nodes0for text nodestimeOrigin + loadTimefor image nodestimeOrigin + renderTimefor text nodesIn addition to the raw span and conventional attributes, we also collect a bunch of ET-specific attributes:
element.type- tag name of the element (e.g.imgorp)element.size- width x height of the elementelement.render-time-entry.renderTimeelement.load-time-entry.loadTimeelement.url- url of the loaded image (undefinedfor text nodes)element.identifier- the identifier passed to theelementtiming=identifierHTML attributeelement.paint-type- the node paint type (image-paintortext-paint)also some additional sentry-sepcific attributes:
route- the route name, either from the active root span (if available) or from the scope'stransactionNamesentry.span-start-time-source- the data point we used as the span start timeMore than happy to adjust any of this logic or attribute names, based on review feedback :)
closes #13675
also ref #7292