feat(browser): Add timing and status atttributes to resource spans #17562

Lms24 · 2025-09-08T16:04:06Z

UPDATE: This PR was reworked quite extensively in e8fa689. PR description was updated accordingly. Would appreciate a fresh round of reviews!

This PR adds a few attributes to resource.* spans for request timing and status information. Most importantly:

http.request.time_to_first_byte from responseStart which can be interpreted as TTFB for resource requests. This was requested via via [Performance] Include TTFB metric to the timing information of a resource in the event details sentry#63739.
http.response.status_code the status code of the resource request. Requested in Capture Status Code for Resource Requests in Sentry #16805 and [Span Statuses] Add status of resource request to span #10995

To get these attributes, I adjusted the already existing resourceTimingToSpanAttributes a bit:

Moved it from browser to browser-utils because resource spans logic is located in browser-utils (this is safe, it never was exported from browser)
Changed the signature to return an object instead of an array of attributes. This is more ergonomical to use in both callsites and should reduce bundle size slightly
Added http.request.redirect_end, http.request.worker_start attributes which are stable timing values available on PerformanceResourceTiming but were previously missing
- Also added to conventions: feat(http): Add new http.request.worker_start and http.request.redirect_end attributes sentry-conventions#130
Added http.request.time_to_first_byte. Decided to add this attribute because http.request.response_start cannot be directly used as TTFB as its value is an absolute time stamp of responseStart. Instead the TTFB attribute is the relative response start attribute converted to seconds (happy to change to ms if reviewers prefer).
- Also added to conventions: feat(http): Add http.request.time_to_first_byte attribute sentry-conventions#131

Other consequences:

http.client spans now also have the three additional attributes

Remarks:

Not super happy about us always defaulting to 0 in case a value is not present. But decided to leave this as-is to avoid any behaviour change for http.client spans.

closes #16805
closes #10995
closes #17554
ref getsentry/sentry#63739

github-actions · 2025-09-08T16:10:29Z

size-limit report 📦

⚠️ Warning: Base artifact is not the latest one, because the latest workflow run is not done yet. This may lead to incorrect results. Try to re-run all tests to get up to date results.

Path	Size	% Change	Change
@sentry/browser	24.17 kB	-	-
@sentry/browser - with treeshaking flags	22.75 kB	-	-
@sentry/browser (incl. Tracing)	40.17 kB	+0.03%	+11 B 🔺
@sentry/browser (incl. Tracing, Replay)	78.53 kB	-0.01%	-1 B 🔽
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	68.26 kB	-0.03%	-17 B 🔽
@sentry/browser (incl. Tracing, Replay with Canvas)	83.19 kB	-0.03%	-21 B 🔽
@sentry/browser (incl. Tracing, Replay, Feedback)	95.4 kB	-0.04%	-37 B 🔽
@sentry/browser (incl. Feedback)	40.9 kB	-	-
@sentry/browser (incl. sendFeedback)	28.82 kB	-	-
@sentry/browser (incl. FeedbackAsync)	33.76 kB	-	-
@sentry/react	25.91 kB	-	-
@sentry/react (incl. Tracing)	42.17 kB	+0.05%	+20 B 🔺
@sentry/vue	28.66 kB	-	-
@sentry/vue (incl. Tracing)	41.98 kB	+0.04%	+15 B 🔺
@sentry/svelte	24.2 kB	-	-
CDN Bundle	25.76 kB	-	-
CDN Bundle (incl. Tracing)	40.06 kB	+0.06%	+21 B 🔺
CDN Bundle (incl. Tracing, Replay)	76.3 kB	-0.03%	-22 B 🔽
CDN Bundle (incl. Tracing, Replay, Feedback)	81.79 kB	+0.01%	+7 B 🔺
CDN Bundle - uncompressed	75.28 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	118.57 kB	+0.06%	+64 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed	233.67 kB	+0.03%	+64 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	246.43 kB	+0.03%	+64 B 🔺
@sentry/nextjs (client)	44.17 kB	+0.05%	+18 B 🔺
@sentry/sveltekit (client)	40.61 kB	+0.04%	+13 B 🔺
@sentry/node-core	49.85 kB	-	-
@sentry/node	151.13 kB	-	-
@sentry/node - without tracing	91.73 kB	-	-
@sentry/aws-serverless	105.19 kB	-	-

View base workflow run

AbhiPrasad

Before this get merged in, let's make sure they are documented in https://github.com/getsentry/sentry-conventions (and adjust the conventions accordingly if there are differences).

A while ago I also did this write up for uptime spans: https://www.notion.so/sentry/Uptime-Span-Conventions-1eb8b10e4b5d80799c70cec9a8a06402#1eb8b10e4b5d80799c70cec9a8a06402

Lms24 · 2025-09-08T16:41:09Z

Good points, thanks Abhi!

So IIUC the notion doc correctly, the SDK should do the calculations for the specific phases in the request life cycle ("durations") instead of sending the raw start/end timestamp values? And in addition, send ttfb instead of something like response.start?
I'm technically fine with this but the disadvantage is likely bundle size and the SDK having to be smarter than necessary. Not opposed to it, just wondering what direction we should go with this.

I'll add whatever attributes we settle on to the conventions repo!

AbhiPrasad · 2025-09-08T16:43:37Z

@Lms24 sorry I should have made this more clear. I prefer the approach you have in this PR. Let's just send as much data as we can, minimizing transforms in the SDK.

We can easily materialize this into the attributes that match what we have for uptime in Relay or during query time in the product.

I just shared the notion doc as an FYI.

github-actions · 2025-09-09T08:25:36Z

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
⚠️ Warning: Base artifact is not the latest one, because the latest workflow run is not done yet. This may lead to incorrect results. Try to re-run all tests to get up to date results.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	9,205	-	8,916	+3%
GET With Sentry	1,325	14%	1,261	+5%
GET With Sentry (error only)	5,993	65%	5,771	+4%
POST Baseline	1,181	-	1,176	+0%
POST With Sentry	467	40%	467	-
POST With Sentry (error only)	1,062	90%	1,065	-0%
MYSQL Baseline	3,348	-	3,305	+1%
MYSQL With Sentry	461	14%	431	+7%
MYSQL With Sentry (error only)	2,681	80%	2,718	-1%

View base workflow run

Lms24 · 2025-09-09T11:07:37Z

I update this PR to use resourceTimingToSpanAttributes which already added most of the timing attributes to http.client spans. We should stick with consistent logic, especially since both, resource.* and http.client spans take its timing data from PerformanceResourceTiming performance entries.

Lms24 · 2025-09-09T11:08:26Z

packages/browser-utils/test/metrics/elementTiming.test.ts

I just moved this and the file below because these were incorrectly nested previously

Lms24 · 2025-09-09T11:09:04Z

packages/browser/src/tracing/request.ts

      if (isPerformanceResourceTiming(entry) && entry.name.endsWith(url)) {
-        const spanAttributes = resourceTimingToSpanAttributes(entry);
-        spanAttributes.forEach(attributeArray => span.setAttribute(...attributeArray));
+        span.setAttributes(resourceTimingToSpanAttributes(entry));


resourceTimingToSpanAttributes now directly returns an array, so we can directly call spanSetAttributes here. Saves a few bytes.

Lms24 · 2025-09-09T11:11:12Z

packages/browser-utils/src/metrics/resourceTiming.ts

+    // For TTFB we actually want the relative time from timeOrigin to responseStart
+    // This way, TTFB always measures the "first page load" experience.
+    // see: https://web.dev/articles/ttfb#measure-resource-requests
+    'http.request.time_to_first_byte': (resourceTiming.responseStart ?? 0) / 1000,


Curious on reviewers' opinions on this one: I decided to convert this value to seconds to stick with us mostly sending seconds-based values. Happy to leave at ms if reviewers prefer.

In terms of keeping the standard of seconds I would keep seconds here. It's a decimal number, right?

s1gr1d

Nice!

s1gr1d · 2025-09-12T12:08:32Z

packages/browser-utils/src/metrics/resourceTiming.ts

+    // For TTFB we actually want the relative time from timeOrigin to responseStart
+    // This way, TTFB always measures the "first page load" experience.
+    // see: https://web.dev/articles/ttfb#measure-resource-requests
+    'http.request.time_to_first_byte': (resourceTiming.responseStart ?? 0) / 1000,


In terms of keeping the standard of seconds I would keep seconds here. It's a decimal number, right?

s1gr1d · 2025-09-12T12:09:44Z

dev-packages/browser-integration-tests/suites/tracing/metrics/pageload-resource-spans/test.ts

+      'http.request.worker_start': expect.any(Number),
+      'http.request.response_end': expect.any(Number),
+      'http.request.response_start': expect.any(Number),
+      'http.request.time_to_first_byte': expect.any(Number),


Kinda related to the other comment: Maybe we can check here that it's a decimal number.

Hmm so theoretically, this could also be an integer, if TTFB happens to be exactly 1000ms for example. We could test against something like expect(Number.isIntegrer(attributes['http.request.time_to_first_byte'])).toBe(false) but this could introduce flakiness (albeit unlikely). WDYT about rather doing a range check instead? 0 < ttfb < 10?

Lms24 requested review from a team, stephanie-anderson, chargome, AbhiPrasad and s1gr1d and removed request for a team, stephanie-anderson and chargome September 8, 2025 16:18

Lms24 mentioned this pull request Sep 8, 2025

[Performance] Include TTFB metric to the timing information of a resource in the event details getsentry/sentry#63739

Open

Lms24 self-assigned this Sep 8, 2025

AbhiPrasad reviewed Sep 8, 2025

View reviewed changes

This comment was marked as outdated.

Sign in to view

Lms24 force-pushed the lms/feat-browser-resource-span-attributes branch from 75a4073 to 5a11163 Compare September 9, 2025 10:57

This comment was marked as outdated.

Sign in to view

Lms24 commented Sep 9, 2025

View reviewed changes

Lms24 requested a review from AbhiPrasad September 9, 2025 11:12

This was referenced Sep 9, 2025

feat(http): Add new http.request.worker_start and http.request.redirect_end attributes getsentry/sentry-conventions#130

Merged

feat(http): Add http.request.time_to_first_byte attribute getsentry/sentry-conventions#131

Merged

s1gr1d approved these changes Sep 12, 2025

View reviewed changes

Lms24 added 4 commits September 12, 2025 16:44

feat(browser): Add timing and status atttributes to resource spans

0a38dc6

adjust attribute names

ace4f38

add unit tests for attribute extraction

0da56f5

adjust integration test

fe24c43

Lms24 added 8 commits September 12, 2025 16:44

fix webkit test

6d59bb0

size limit

37edc3e

rework implementation to use resourceTimingToSpanAttributes

ce5c8e6

add new attributes to http timing test

c608dab

lint

4ebf1f7

fix browser utils unit tests

993c23b

remove unused types

dc2085d

check for ttfb in seconds range

32b3717

Lms24 force-pushed the lms/feat-browser-resource-span-attributes branch from c3bad5e to 32b3717 Compare September 12, 2025 14:44

Lms24 merged commit 7c41f03 into develop Sep 12, 2025
275 of 276 checks passed

Lms24 deleted the lms/feat-browser-resource-span-attributes branch September 12, 2025 15:34

This was referenced Sep 16, 2025

[Span Statuses] Add status of resource request to span #10995

Closed

Capture Status Code for Resource Requests in Sentry #16805

Closed

Add resource request timing data to resource spans #17554

Closed

Uh oh!

feat(browser): Add timing and status atttributes to resource spans #17562

feat(browser): Add timing and status atttributes to resource spans #17562

Uh oh!

Conversation

Lms24 commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

size-limit report 📦

Uh oh!

AbhiPrasad left a comment

Choose a reason for hiding this comment

Uh oh!

Lms24 commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AbhiPrasad commented Sep 8, 2025

Uh oh!

github-actions bot commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

node-overhead report 🧳

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as outdated.

Uh oh!

Lms24 commented Sep 9, 2025

Uh oh!

Lms24 Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

Lms24 Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

Lms24 Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

s1gr1d Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

s1gr1d left a comment

Choose a reason for hiding this comment

Uh oh!

s1gr1d Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

s1gr1d Sep 12, 2025

Choose a reason for hiding this comment

Uh oh!

Lms24 Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Lms24 commented Sep 8, 2025 •

edited

Loading

github-actions bot commented Sep 8, 2025 •

edited

Loading

Lms24 commented Sep 8, 2025 •

edited

Loading

github-actions bot commented Sep 9, 2025 •

edited

Loading

Lms24 Sep 12, 2025 •

edited

Loading