b2KIT

JavaScript Profiler

Profile JavaScript code execution time with function-level timing, call count, and performance flame chart.

Tested tool guide Tested browser tools Checked August 16, 2026

What JavaScript Profiler does and how it behaves

JavaScript Profiler runs entered JavaScript and presents the observed execution as function timings, invocation counts, and a flame chart of nested calls. The summary helps separate a function called once for a long time from a small function called repeatedly. The most important surprise is that timing is not a deterministic output: identical code can produce different measurements across runs because browser and system activity affect execution. Profiling happens in the browser, so the entered code and resulting measurements are not uploaded.

How the result is produced

1

Function measurements

Each profiling run executes the entered program and associates observed execution time with the functions represented in the results. The call count records how many times each function ran during that execution. Repeated invocations therefore increase the count and contribute additional measured work. These figures characterize one run with one input and browser state; they do not establish a permanent runtime for the code.

2

Flame chart reading

The flame chart arranges recorded calls by time and nesting. A block's horizontal width represents its share of the displayed execution span, while vertically stacked blocks connect callers with functions they invoked. This view is useful for tracing a long interval through several call levels. Consult the function summary alongside it to distinguish a broad single call from accumulated cost across many calls.

Good uses

  • Profile two implementations of the same parsing or transformation task with identical input, then compare which functions account for the observed execution time in each run.
  • Investigate an unexpectedly expensive loop by checking whether a helper, callback, or recursive function has a much higher call count than the source code initially suggests.
  • Follow a slow top-level operation through nested function calls in the flame chart to identify the call path containing the largest measured spans.

Limits and checks

  • Treat small timing differences cautiously. Just-in-time compilation, garbage collection, other tabs, background processes, CPU power management, and browser scheduling can change measurements without any source-code change.
  • Do not assume that every reported duration means self time. A duration that includes nested callees cannot be added to those callee durations without double-counting. Use explicit self or total labels if the result provides them.
  • The entered program actually runs, so initialization, mutation, randomness, cached data, and earlier iterations can affect later measurements. A warm run and a cold run may answer different performance questions.

Common questions

Can I treat one profiler run as a benchmark result?

No. One run is useful for locating expensive functions and excessive call counts, but it is weak evidence for a stable performance comparison. Run each candidate repeatedly under comparable conditions, include any intended warm-up, keep the input unchanged, and compare the distribution of results. Large, repeatable differences are more meaningful than a small difference observed once.

Why might the function times not add up to the overall duration?

Nested calls occupy time already contained within their caller's interval, so adding both can count the same span twice. Execution outside the listed function records can also contribute to the complete run. Check whether displayed values are identified as self time or total time. If that distinction is absent, use the flame chart for call relationships rather than assuming the values are additive.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools