Discussion: Using server-provided trace context from meta tags for browser telemetry

[martinkuba]

Background

When a backend serves an HTML page, it can embed trace context in a meta tag (e.g., <meta name="traceparent" content="00-...">). This allows the browser to associate telemetry with the server-side trace that generated the page.

This approach was implemented in the existing document load instrumentation and was also proposed as part of the console instrumentation in PR #98.

Questions for Discussion

1. Is this a mechanism we want to continue supporting in general?

2. Should trace context from a meta tag be attached to all signals generated during the page lifetime?

   • it makes sense for document load to correlate page load timing with the backend request
   • should console logs, user interactions, or other events that occur minutes/hours after page load also be associated with the original backend trace?

3. If yes, what are the concrete use cases?

4. Is this an outdated model?

   • This approach assumes a single "page trace" model, but we've moved toward using sessions to represent page lifetime rather than a single trace.
   • User actions later in the page (clicks, form submissions) typically trigger new XHR/fetch requests, which start their own traces and should be correlated with those backend requests, not the original page load.

Alternatives

1. Use document.instance.id or similar attribute to correlate all events from a single page view without implying a trace parent-child relationship. See related discussion in Events breadcrumbs: introduce a context identifier #84
2. Keep it only for document load instrumentation (which generates a span, not log/event)
3. Make it configurable per-instrumentation - allow users to opt-in to this behavior where it makes sense for their use case.