Profiler

Profiler lives in the Monitor area of the dashboard, under Performance.

At a glance#

What it does#

The Profiler lists JS self-profiling traces captured from real user sessions and, for the selected trace, aggregates it into a hotspot table — self time and total time per function. Each trace records the session, screen, duration and sample count.

ProfilerView full size

010203

01Read profiling healthCompare captures, on-CPU samples, idle share, incidents, auto-capture, and the hottest function.02Interpret the captureThe legend explains total width, self-time colour, and why an idle sample is not automatically fast.03Open the affected experienceThe incident row connects magnitude and route to the replay that proves what the user experienced.

Profiler

This is the deepest view in Monitor. Jank tells you which script blocked; the profiler tells you which function, sampled on a real user's device rather than yours.

When to use it#

Last. When you know a screen is slow, you know roughly where, and the remaining question is which function to change. Reaching for a profiler before you have narrowed the problem produces a lot of data and no decision.

Workflow#

1. 1

   Pick a trace from a slow screen

   Duration and screen name are on each row. A trace from a fast session teaches you nothing.

2. 2

   Sort hotspots by self time

   Self time is where the CPU actually was. Total time includes everything a function called, so it will rank your entry point first and tell you nothing.

3. 3

   Cross-check against sample count

   A profile with few samples is a short observation window. Treat single-sample frames as noise.

Permissions and prerequisites#

Web apps only, and only in browsers that implement JS self-profiling. Combined with the header requirement, expect this to cover a subset of your traffic rather than all of it — which is fine for profiling, where you need representative traces rather than complete coverage.

Limits and edge cases#

• Sampling, not tracing. The profiler observes at an interval, so it reliably finds hot functions and reliably misses fast infrequent ones.

• Function names depend on your build. Minified output produces minified frames. Ship source maps if you want readable hotspots.

• Not available on mobile. There is no equivalent capture, and this route is hidden for mobile apps rather than shown empty.

Troubleshooting#

No traces at all. Check the Document-Policy: js-profiling header on the document response, in production, on the origin your users actually hit — a header set in local dev proves nothing.

Hotspots are all single letters. That is minified code. Frames are accurate; only the names are lost.

Where the data comes from#

Capture requires the document to be served with Document-Policy: js-profiling — a server or CDN header, not an SDK setting.

From the SDK

• Performance

Served by

• Dashboard

Related#

• Overview

• Insights

• App start

• RUM overview

• Web Vitals

• Network

• Monitor overview