enablePerformanceTracks
Paint the attribution engine's records — and the web runtime's
server-function call and frame records, with the server's own timing
for each response under them (its Server-Timing metrics, placed by the
browser's resource timing; the document's at enable) — as tracks in the
Chrome Performance panel, from now until the returned function is called. The
tracks themselves are Chrome's (its detail.devtools extension); in rich
mode the spans are standard User Timing measures underneath, so any tool
that reads those — Firefox's profiler, Lighthouse, RUM — sees the same
spans as plain measures.
Takes its own hold on the engine (attribution.enable): enabling beside
a diagnostics capture or an APM adapter disturbs neither, and releasing
here leaves theirs in place. Subscribing
to the engine's timeline records (create, effect, flush, flight,
fallback) is what turns them on — they are built only while a listener
exists, so the engine pays for them only while the tracks are enabled.
Every diagnostic delivered while enabled becomes a marker on the panel's
Timings track (SILENT_HOLD — <Search>), annotated as a
performance issue for the Insights sidebar when its severity is a
warning or worse. In dev, spans and markers are emitted inside the
console.createTask task of the component they belong to, so an entry's
stack in the panel points at the JSX site that rendered the component.
One instance per page: the tracks are a view of one engine, and a second
painter would paint every span twice. A call while enabled joins the
running instance — its options are not re-read; the first call's apply —
and returns a release of its own; the instance is torn down when every
release has been called (a module re-evaluated by HMR that enables again
and disposes the old one lands back on one instance either way). A no-op
(returning a no-op) in prod builds, where the observe tier is absent, and
in an environment without console.timeStamp or performance.measure.
Import
import { enablePerformanceTracks } from "@solidjs/web/performance-tracks";Type signature
function enablePerformanceTracks( options: PerformanceTracksOptions = {}): () => void;Parameters
options
- Type:
PerformanceTracksOptions - Optional
Learn more
Related types
PerformanceTracksOptions
interface PerformanceTracksOptions { attribution?: AttributionOptions; minMs?: number; rich?: boolean;}attribution
- Type:
AttributionOptions
Options for the engine hold this adapter takes
(attribution.enable({ log: false, checks: false, ...attribution })).
The adapter asks for no console log and records only — the timeline is
the output — which, the engine combining holds by the most demanding
request, quiets the console and the cost checks (hotRuns, hotTime,
wideDeps, unstableMemos, fanOut, wastedRecompute) only while
nobody else wants them: a console session beside the tracks keeps its
log and its checks. Pass checks: true to have the tracks' own hold
run them, their findings painted as markers like any other.
minMs
- Type:
number
Floor for run spans on Propagation, Effects and Memos — compute
runs (by totalMs), creation runs and effect callbacks (by their
duration): spans under it are not painted. The wave span on
Propagation always is, and its label carries the counts, so a
fan-out of runs too small to paint still reads as 47 runs. Default
0 in dev (every run; Chrome shows zero-width spans zoomed in) and
0.05 in observe builds, so a production trace carries the runs that
cost something.
rich
- Type:
boolean
Emit through performance.measure with detail.devtools — tooltips
(the why-chain of a re-run) and properties (causes, deps, blockers…)
on every span — instead of console.timeStamp. Costs a User Timing
entry per span; the adapter clears the entries it made in batches (a
name it shares with an app measure is left alone). Default: dev builds.
Each path falls back to the other where its API is missing.