Scenario · Rendering
Counter
The classic, and the baseline every other scenario is measured against: one click is one
onclick → Counter.IncrementCount event and one render of Counter, nothing else.
The counter
The second button increments ten times from one event, calling StateHasChanged and awaiting
between the steps - ten renders that all trace back to a single click.
Current count: 0
Timeline: one click, one render
Open the Timeline and click Click me: the onclick → Counter.IncrementCount
event, the one batch it produced and the render of Counter inside it - no layout, header or
other page component renders with it. The ten-step button shows ten renders caused by the same event, and
Diagnostics calls it a slow event handler: a handler's duration spans every
await inside it, about 300 ms here.
Profiler: what did this one click cost?
In the Profiler, press Reset, click once and tick since reset: one row, one render. Compare with one keystroke on the Products page.
Visit a few pages and come back, then open Renders per page → Show: each page with its visits, renders, render time and the three components that cost the most there. This page sits near the bottom; the dashboard with its clock ticking sits near the top.
Components: where it is written
Select Counter in the Components tab. Type & source links
Counter.razor, and Event handlers & callbacks lists both buttons -
onclick → Counter.IncrementCount and Counter.IncrementTenTimes - each with a link to the line
that handler is written on. The links open your editor (VS Code by default; Ui.EditorUrlTemplate
changes it) and come from the app's symbols; without them the location is inferred from the type name and
labelled so.