+ A React app slows down one wasted render at a time. From the outside + the app just feels slow. From the inside, you are guessing which + component, and why. The profiler shows you every render and ranks + none of them. +
+
+
+ /gaia-react-perf
+
+ {
+ ' drives the interaction you point it at and captures real per-render attribution. The capture runs on the same React instrumentation that powers '
+ }
+
+ react-scan
+
+ , wired into Claude, not a browser overlay. It surfaces two failure
+ modes: a memoized component that re-renders anyway because a prop or
+ context value it depends on is a new object or callback every
+ render, and any component whose render crosses a 16 ms frame budget,
+ memo or not. It skips the cheap re-renders that push you toward
+ memoizing everything, then names the structural fix for what is
+ left.
+
+ Ranked findings +
+ {FINDINGS.map((finding, index) => ( ++ {finding.memoDefeated > 0 ? + `${finding.renderCount} renders · ${finding.memoDefeated} memo-defeated` + : `${finding.renderCount} renders`} +
+ {finding.inputs.length > 0 ? ++ + {finding.source === 'context' ? + 'unstable context: ' + : 'unstable props: '} + + + {finding.inputs.join(', ')} + +
+ : null} + {finding.cause ? ++ {'react-doctor · '} + {finding.cause} +
+ : null} ++ Diagnosis +
++ Two findings cross the 16 ms frame budget, and the fixes differ. + Give OrdersTable stable props so its memo holds, then cut the + per-render work in RevenueChart, which has no memo at all. +
++ Measure-only: GAIA diagnoses, Claude applies the fix you approve, then + re-runs /gaia-react-perf to confirm the finding drops to zero. +
+ + {/* Meta strip */} +