Scan the codebase for React Native performance antipatterns and report ranked findings. Use for a performance review, a slow app, or a perf audit before release.
Installs into .claude/skills of the current project.
Are you the author of Perf Audit?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/anilburcu-perf-audit)
---
name: perf-audit
description: Scan the codebase for React Native performance antipatterns and report ranked findings. Use for a performance review, a slow app, or a perf audit before release.
argument-hint: "[path to focus on]"
---
Audit the codebase (or the path in `$ARGUMENTS`) for the React Native performance antipatterns that actually matter. Read-only: report, do not edit.
Hunt for these, in priority order:
1. **Lists**: ScrollView wrapping `.map()` over data of meaningful size; FlatList/FlashList with inline arrow `renderItem`; missing or index-based `keyExtractor`; list images without fixed dimensions.
2. **Subscriptions**: components subscribing to whole stores (`useStore()` with no selector, or selectors returning fresh objects); context providers bundling fast-changing values with static ones.
3. **Render work**: heavy computation directly in render without memoization; date/number formatting per row per render; JSON.parse of large payloads on the interaction path.
4. **Animations**: setState driving per-frame animation; runOnJS inside gesture or frame callbacks; PanResponder where gesture-handler belongs; animating layout properties instead of transform/opacity.
5. **Startup**: heavy SDK/analytics initialization at module top level; barrel imports that pull the world into the entry file; synchronous storage reads before first render.
6. **Leftovers**: console.log in hot paths that ship to release; dev-only tooling imported unconditionally.
Method: grep for the patterns, then READ each hit before reporting it. A ScrollView over four static children is fine; the same over a fetched array is a finding. Judgment beats pattern-matching, and false accusations burn the reader's trust in the whole report.
Report format:
- Ranked findings, worst first. Each: `file:line`, the pattern, why it costs here specifically, and the one-line direction of the fix.
- Skip theory. No finding, no entry; an honest "lists are clean" beats padding.
- Close with the top three fixes worth doing this week. Verification means re-measuring in a release build, not eyeballing the simulator; say so at the end of the report.
