How do you catch RN performance regressions?

WHAT THIS TESTS: Whether you treat performance as a measured, regression-gated discipline rather than a subjective impression, and know the relevant metrics and tools.

A GOOD ANSWER COVERS: Start by defining the metrics that map to user experience. Time-to-interactive, or cold-start TTI, captures startup cost. JS thread frames per second reveals whether logic is starving the frame loop, while UI thread FPS reveals native rendering stalls; both matter because jank can originate on either thread. You also track scroll performance, interaction latency, bundle size, and memory footprint. The method is to establish baselines on representative devices, especially low-end Android, then measure repeatedly and compare against those baselines so any regression is detected. Automation is key: a service like Flashlight runs the app and produces a comparable performance score and FPS and CPU traces suitable for CI gating, while the React profiler and React Native DevTools help diagnose which renders or tasks caused a regression, and system tracing gives thread-level detail.

COMMON WRONG ANSWERS: Relying on subjective feel or a single manual run. Testing only on a flagship device, masking problems that hit budget hardware. Tracking a single metric and missing thread-specific issues. Having no baseline, so you cannot tell a regression from normal variance. Confusing JS thread FPS with UI thread FPS.

LIKELY FOLLOW-UPS: How to gate CI on a performance budget, the difference between JS and UI thread jank, how Hermes affects startup metrics, and how the new architecture changes the profile.

ONE CONCRETE EXAMPLE: A team baselines cold-start TTI and scroll FPS on a low-end phone via Flashlight in CI. A pull request adding a heavy synchronous parse on launch drops the score and TTI past the budget, failing the check; the React profiler then pinpoints the offending component, and moving the work off the JS thread restores the baseline before merge.