Adding memoization throughout a slow page can create a large diff without shortening the wait users experience. This skill orders the investigation: examine asynchronous waterfalls and initial JavaScript first, then server work, client fetching, and rendering costs.
Install and invoke
From the project root, use a terminal with Node.js and npm to install this individual skill for Claude Code. For Codex, replace --agent claude-code with --agent codex. This is a project-scoped installation. Refresh or reopen the agent session after installation, then name the skill explicitly in your request.
npx skills@latest add vercel-labs/agent-skills --skill vercel-react-best-practices --agent claude-code
Give the review a measurable target
Adapt this first request to your project:
Use vercel-react-best-practices to inspect app/dashboard and its data access. Reduce the wait on first load. Map request dependencies, identify independent operations and unnecessary initial dependencies, then propose the top three changes with validation methods. Implement only the first after approval, preserving authorization and error states.
Identify a route, a slow interaction, and a repeatable way to reproduce it. Include a network timeline, bundle report, or performance recording when available. Without a baseline, the initial deliverable should be a set of hypotheses and a measurement plan, rather than a claim that the page has become faster. State whether the affected flow is anonymous or authenticated.
Understand dependencies before introducing concurrency
The official parallelization rule applies to operations that do not depend on one another. A profile request and an independent announcement request may run concurrently. A query that needs an identifier or authorization result from another operation cannot simply be moved into the same Promise.all call.
Ask the agent to explain why each operation can start earlier, how errors propagate, and what the user sees when one request fails. Performance changes should preserve permission checks and useful loading or error states. An apparently faster route is not an improvement if it fetches data the current user must not receive.
Next, inspect initial dependencies. Large charts, editors, and third-party code may not be needed immediately. Moving work to the server or loading a component later changes boundaries and loading behavior, so include those effects in the proposed change rather than treating bundle reduction as an isolated edit.
Compare equivalent runs
A useful first result is one targeted change, its tests, and comparable before-and-after observations. Use the same data volume, authentication state, and network conditions. Distinguish development overhead from a production build, and report an existing failure separately from a new regression.
Caching deserves the same care. Deduplicating work within one request differs from sharing results across requests; user-specific data needs an appropriate boundary. The skill supplies a review order and implementation patterns, not a replacement for profiling. If a database query or external service dominates the delay, optimizing component hooks may leave the original problem untouched. Stop after the evidence supports the targeted improvement, then reassess the next bottleneck.
Distinguish three kinds of “slow”
A blank first load, delay after a click and typing jank are often different problems. For first load, inspect request waterfalls and JavaScript bundle cost: are independent requests serialized, or is an editor needed only in a dialog included in the initial bundle? For a slow click, inspect requests and state changes triggered by that action. Typing lag is more likely to need component render analysis. Ask the agent to name the wait it is targeting and a reproducible path.
Draw dependencies before removing a waterfall. Query A may need the authenticated user ID and must wait; public announcement B may run independently. Concurrency changes also alter partial-failure behavior, which the UI must handle. Code splitting has a cost too: opening a lazily loaded editor may be slower on first use, so plan its loading state and any prefetching. Fewer requests alone do not prove a better experience.
Another case: a chart loads before anyone opens it
If a product page shows a trend chart only after “View trends” is clicked, ask: “Check whether the chart library is in the product page’s initial bundle. Preserve data permissions and dialog loading states. Propose the smallest change to load chart code on expansion, and explain what delay first open will add.” This applies the official bundle and dynamic-import guidance without assuming code splitting always improves the experience. Compare initial bundle or download time, first chart-open delay, slow-network placeholder and failure message. If most visitors open the chart immediately, prefetching may be worth considering; a smaller initial bundle alone is not the final measure.
Apply the rules to a specific review
Use this as a code-review checklist during component work, not only after a page feels slow. A shadcn registry author uses it to steer an agent away from derived state in useEffect and to check independent fetches for parallelism. Pick one issue present in the current page, measure the existing behavior, change it, and retest; matching a rule alone does not prove a user-visible speedup.
If the installed skill never activates
If the skill is installed but never fires, check whether this runtime treats the react-best-practices directory and declared vercel-react-best-practices name as the same skill. A user found the mismatch left it mounted but unresolvable in their environment. Have the agent open the actual SKILL.md, then review a specific component, to confirm the rules are in play.