Developer pack
Claude Skill
React Performance Reviewer
Reviews and refactors React/Next.js code against the performance rules that actually move load time — waterfalls, bundle size, server cost, re-renders.
What it does
Audits React and Next.js components and data fetching against a prioritized rule set — eliminating request waterfalls, bundle-size cuts, server-side cost, re-render reduction — and rewrites the hot spots. Catches the quiet patterns that cost real seconds: barrel imports, serial awaits, components subscribing to state they only read in callbacks.
When to use
- ✓A page is slow, TTFB is high, or the JS bundle is heavy
- ✓Reviewing a React/Next PR specifically for performance regressions
- ✓Writing new Server Components or data fetching and want it fast by default
When not to use
- ✗The stack isn't React/Next — the rules are framework-specific
- ✗It's a correctness bug, not a speed problem (use the debug helper instead)
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/react-performance-reviewer.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: react-performance-reviewer
description: Use when writing, reviewing, or refactoring React/Next.js code for performance. Triggers on "slow page", "big bundle", "high TTFB", "too many re-renders", or a perf review of React/Next code.
---
# React Performance Reviewer
Most React performance loss is structural, not micro. Fix the order of operations (waterfalls), the amount of JavaScript shipped (bundle), and what re-renders, and the page gets fast. `useMemo` sprinkled everywhere is not the answer and usually makes it worse.
## Review in priority order
Work top-down — the high-priority categories carry almost all the wins.
1. **Eliminate waterfalls (critical).** Independent awaits should run in `Promise.all`, not in series. Start promises early and await late. Check cheap sync conditions before awaiting remote ones. Use Suspense boundaries to stream.
2. **Cut bundle size (critical).** Import directly, not through barrel files. Use dynamic imports for heavy components. Defer third-party scripts (analytics, logging) until after hydration. Keep import paths statically analyzable.
3. **Server-side cost (high).** Dedupe per-request work with `cache()`. Minimize the data serialized into client components. Hoist static I/O (fonts, logos) to module level. Parallelize nested fetches.
4. **Re-render reduction (medium).** Don't subscribe to state you only read in a callback. Derive state during render instead of in an effect. Use functional `setState` for stable callbacks. Split hooks with independent dependencies. Use `startTransition` for non-urgent updates.
## Output
For each finding: the rule it violates, the specific line, why it costs, and the rewritten code. Lead with the critical-category fixes — don't bury a waterfall fix under five micro-optimizations.
## Anti-patterns (in the code AND in the review)
- Serial `await` on independent data — the most common real slowdown
- Barrel-file imports that drag a whole library into the bundle
- Wrapping trivial primitive expressions in `useMemo` — noise, not speed
- Subscribing a component to a value it only uses inside an event handler
- Reviewing micro-optimizations while a request waterfall sits untouched
Example prompts
Once installed, try these prompts in Claude:
- Review this Next.js page for performance — TTFB is ~1.8s and the client bundle is 400KB.
- This dashboard re-renders the whole tree on every keystroke. Find the cause and fix the re-render path.