Browser profiling

The browser SDK can sample JavaScript call stacks with the JS Self-Profiling API and show them in Profiles (source=browser) and on the session page.

Enable

init({ publishableKey, endpoint, service: "web", profiling: true });

Or switch it on in the project's remote config (profiling.enabled); remote config wins over the local option, so it is also the kill switch.

The page must be served with the response header Document-Policy: js-profiling. Without the header, or in a browser without Profiler, the SDK profiles nothing and sets the session attribute wt.sdk.profiling=unsupported.

What is sampled

• 5% of sessions (decided once per session), at most one 10 s window per view, started 3 s after the view so replay start is never profiled.

• new Profiler({sampleInterval: 10, maxBufferSize: 10000}); the trace is converted to folded stacks, frames function@file:line (query and fragment dropped from file URLs).

• Source maps are resolved server side through the debug-id path used for JS errors.

Upload

POST /v1/rum/profiles?service=&release=&route=&session=&trace= with the publishable key and an allowed origin. Body: folded text, at most 512 KiB (413 above). Counted in the per-key rate limit. The edge produces it to wt.profiles (wt-format=folded) with labels source=browser, route, session_id and trace_id; tenant identity comes from the key only.