Component Render Profiler

Show which components re-render, what triggered it, and which of those actually cost anything.

involved Front-End Performance

What it adds

A development-only instrument that records render counts, their causes, and their durations for the app's live screens.

What your agent is told to do

1
Instrument the app's real screens rather than a test harness. Re-render problems come from the shape of actual data and actual state, and they do not reproduce on three sample rows.
2
Record for each render what changed to cause it, distinguishing a changed input, a state update in the component itself, and a shared value that changed above it.
3
Report duration alongside count, and sort by total time spent. A component that renders two hundred times cheaply matters less than one that renders four times and blocks the main thread each time.
4
Make the instrument switchable at runtime behind an internal control, and make it inert in production builds — measurement is itself a cost, and it must not be one that customers pay.
5
Do not conclude that a frequently rendering component should be memoised. Comparison has its own cost, and the usual real cause is a value being newly constructed on every render above it, which memoising the child does nothing to fix.

Edge cases it handles

Profiling must be off and ideally absent in production builds, since the instrumentation itself changes the timings it reports and adds weight for every user.
Render count alone is misleading; the report must separate the renders that consume real time from the ones that are effectively free, or the first thing anyone optimises is the wrong thing.
The cause of each render must be traceable to a specific changed input, local state update, or shared value — a report saying only that something re-rendered gives nobody anywhere to start.
The tool must not push memoisation as a default remedy, because it frequently adds comparison cost while leaving the newly constructed value that actually caused the problem untouched.
Long lists will dominate any report simply by being long. Aggregate repeated instances of the same component so one row does not hide everything else.
The profiler's own output must not be rendered inside the tree it is measuring, or it will show up in its own numbers.
Timings vary between runs and between machines, so the report should show a distribution or several samples rather than a single figure presented as fact.

Definition of done

Render counts, causes, and durations are recorded for the app's real screens.
Each render is attributed to a changed input, local state, or a shared value from above.
The report ranks by total time spent, not by render count.
Profiling is toggleable at runtime and inert in production builds.
Repeated instances of the same component are aggregated rather than listed individually.
The profiler's own interface is excluded from its measurements.
The feature matches the existing design system.
No existing functionality is broken.

Related features

Font Subsetting

Layout Shift Guard

Render Stability Guardrails

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.