Add Browser Resource Timing Event

[Karlie-777]

Fixes #

Changes

Please provide a brief description of the changes here.

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[trask]

@open-telemetry/specs-semconv-maintainers do you see any issue with using url.full for something that doesn't include the query string?

[overbalance]

Some platforms use querystring params to resize images. If you strip it down to just domain and path, you won't have a complete picture of which size assets loaded. I understand the high cardinality issue but wanted to call this case out.

[joaquin-diaz]

Should we include query string separately?

[ladd]

Would it make sense to use integer nanosecond timestamps to be consistent timestamp/duration measurement in the rest of OpenTelemetry

Looking beyond the browser, these are potentially applicable to a native app scenario via vendor APIs like URLSessionTaskTransactionMetrics on iOS.

[trask]

Would it make sense to use integer nanosecond timestamps to be consistent timestamp/duration measurement in the rest of OpenTelemetry

hey @ladd 👋

I think this event is a bit different because we're bridging an external event as-is, and so we are prioritizing preserving the external event structure/names/values over consistency with normal semantic conventions

Looking beyond the browser, these are potentially applicable to a native app scenario via vendor APIs like URLSessionTaskTransactionMetrics on iOS.

@open-telemetry/android-approvers wdyt?

@MSNev @martinkuba how important is it for this event to exactly match the browser event? or would it be ok as long as you have the ability to capture the same set of data, but it was modeled as a generic event with some potentially browser specific attributes on top of it?

[Karlie-777]

For the changelog, it will reuse and update the one from this PR #1940

[MSNev]

@MSNev @martinkuba how important is it for this event to exactly match the browser event? or would it be ok as long as you have the ability to capture the same set of data, but it was modeled as a generic event with some potentially browser specific attributes on top of it?

The case for keeping as is

As this is the browser.resource_timing event, it is very important that this be kept the way the industry and existing solutions (incl OpenTelemetry span events) record and measure these values, otherwise anyone "moving" to this new definition would have to perform backend calculations on every query or on receiving the event when processing this data.

Even in OpenTelemetry there is existing code (hacks) to capture these currently as "Span" events https://github.com/open-telemetry/opentelemetry-js/blob/b322a24b4a3296577fb908c0bc9b33efc57c501e/packages/opentelemetry-sdk-trace-web/src/utils.ts#L63-L127 which record the values as is (which for most browsers will be a zero based "duration" (which is also why the hack to send as a span event (long before logs existed))

The case for Making Consistent

Now if this was (or becomes) a non-browser specific event definition and a general OpenTelemetry Semantic convention for all consumers of different types of "resource" types, then I would 100% agree with aligning and recording as nanoseconds. As a differently named event.

General Background Details

As a general comment, in the browser world nothing is generally recorded in nanoseconds and when it is supported (as a double - as fractional microseconds) it is generally deliberately crippled (by adding random time "adjustments" with both positive and negative values) to avoid being used to "fingerprint" (identify / classify) a specific user / environment. These "adjustments" where added because this was occurring in the real world (with techniques like Canvas fingerprinting)

[martinkuba]

I think this URL is for the resource described by this event, not the page URL, correct? I think we should note this in the description of this attribute, so that it is clear.

Also, if this is the resource URL, why is it listed as an attribute rather than a body field like the measurements?

[martinkuba]

All fields that are available from the browser API are described here
https://www.w3.org/TR/resource-timing/#sec-performanceresourcetiming

This event includes only a subset. I recall we discussed including only the most relevant fields a long time ago in the Client SIG. Now, after another review, I think there are additional fields we might want to consider including, for example:

• transferSize (to determine whether local cache was used)
• decodedBodySize, encodedBodySize (to determine whether the content was compressed)
• nextHopProtocol (to determine if a fast protocol was used)
• additional context: initiatorType, contentType, deliveryType, renderBlockingStatus

This PR has all fields marked as recommended. If we included all the fields and made them all recommended (not required), it could be left to the instrumentation to determine which to include. This could also be configurable, so that users can decide what fields they care about.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[david-luna]

Could we re-open this PR?

[Karlie-777]

This is PR is under open status, still making changes to this PR

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[Karlie-777]

@hectorhdzg will take over this PR and continue addressing comments after #1943 (comment) or he will open a new PR based on this PR.

[Karlie-777]

close this PR since #3069 is opened for the following changes. Thanks @hectorhdzg