render-performancelisted

# Render performance ## Measure first, and say what you measured The single most common mistake here is optimizing a render that was never the problem. Before changing anything: - **React DevTools Profiler** — record the interaction, read which components rendered, how often, and why. "Why did this render?" is the whole question, and the profiler answers it directly. - **The index**, for the mechanical causes: `fe-index signals --rule PERF-INLINE-LITERAL-PROP,PERF-INLINE-FN-PROP,PERF-INDEX-KEY` - **`fe-index impact`** on the component you are considering memoizing — how many places render it, and how often. A performance claim without a measurement or a named mechanism is not a finding. ## The cost model A React re-render is: run the component function, diff the returned element tree, commit the DOM changes that differ. **The render itself is usually cheap; the fan-out is what costs.** One parent re-rendering a hundred children is a hundred function calls and a hundred diffs. So the questions are: what triggers the render, how far does it spread, and how expensive is each node. ## Cause 1 �� identity churn (the most common by far) A new object/array/function literal in props is a new identity every render: ```jsx <List items={data} config={{ dense: true }} onSelect={() => pick(id)} /> ``` Both `config` and `onSelect` are fresh every render. If `List` is memoized, the memo does nothing. If they land in a dependency array, the effect re-runs. Fixes, in order of prefer