React Best Practices

React Best Practices is Vercel Engineering's performance guidance packaged as an agent skill. It covers React and Next.js code: data fetching, bundle size, server components, client fetching, re-renders, rendering, JavaScript micro-optimizations, and advanced patterns.

It is not a profiler and not a benchmark. It is a prioritized checklist that an agent can apply while writing or reviewing code, with individual rule files that show an incorrect and a correct example.

Source and revision

What the skill actually does

The SKILL.md lists 70 rule IDs across eight categories, ordered by impact:

Each rule file contains a short explanation, an incorrect example, a correct example, and references. The skill's AGENTS.md is a compiled version of the full guide.

Examples of the rules:

• async-parallel: independent awaits should run in Promise.all().
• bundle-barrel-imports: import directly instead of pulling a barrel file into the bundle.
• server-cache-react: use React.cache() for per-request deduplication.
• rerender-derived-state-no-effect: derive state during render, not in an effect.
• rendering-content-visibility: use content-visibility for long lists.
• js-early-exit: return early from functions.

The rules are practical because they are specific enough to review. "Optimize images" is not a rule. "Use next/dynamic for heavy components" is.

A real inconsistency to know about

The SKILL.md says 70 rules. The repository README and the compiled AGENTS.md abstract say "40+ rules." The rule ID list in SKILL.md is the concrete inventory; the 40+ phrasing is older marketing copy. If you are citing a count, cite the list you actually inspected, not the README.

The license is also split: the skill frontmatter declares MIT, and the plugin metadata may declare MIT, but the repository has no root license file at this revision. That is enough to treat the skill text as MIT-declared, but it is not the same as a repository-wide license audit. We did not embed the rule text; the page links to the pinned source.

Illustrative refactor

This is a constructed example, not an executed benchmark.

Before:

export default async function Dashboard() {
  const user = await getUser();
  const posts = await getPosts();
  const comments = await getComments();

  return <DashboardView user={user} posts={posts} comments={comments} />;
}

The three fetches are independent, so awaiting them in sequence creates a waterfall.

After:

export default async function Dashboard() {
  const [user, posts, comments] = await Promise.all([
    getUser(),
    getPosts(),
    getComments(),
  ]);

  return <DashboardView user={user} posts={posts} comments={comments} />;
}

That is the async-parallel rule. The upstream rule file describes the sequential version as three round trips and the parallel version as one, with a "2-10x improvement" impact label. That label is the author's estimate, not a measurement of your app. Measure with your own profiler before claiming a gain.

A second pass might apply bundle-barrel-imports:

// Before: pulls the whole barrel into the graph
import { Button } from "@/components";

// After: imports the module directly
import { Button } from "@/components/ui/button";

Again, the benefit depends on the bundler and the barrel's contents. The rule tells you where to look; it does not prove the bundle shrank.

When to use it

• Writing new React components or Next.js pages.
• Reviewing a pull request for performance issues.
• Refactoring data fetching, bundle imports, or re-render behavior.
• Establishing a shared vocabulary for frontend review.
• You want an agent to apply a consistent checklist instead of ad hoc micro-optimizations.

When not to use it

• You need to know whether the page is actually slow. Use Web Performance Audit or a profiler first.
• The code is not React or Next.js. The rules are framework-specific.
• You want a blanket "useMemo everywhere" pass. Several rules explicitly say not to memoize simple primitives.
• You need a security or accessibility review. This is performance guidance.
• You need a license opinion. The per-file MIT declaration is evidence, but the missing root license is a scope gap worth resolving with the maintainer.

Install

npx skills add vercel-labs/agent-skills --skill react-best-practices -a claude-code

Prerequisites and footprint

The compiled AGENTS.md is useful for agents that read a single file, but loading it defeats progressive disclosure. Prefer the core file plus the specific rule files.

Limitations

• Rule counts disagree. 70 in SKILL.md, "40+" in the README and compiled abstract. Cite the concrete list.
• No root license file. MIT is declared per skill, but repository-wide scope is not documented in a root LICENSE.
• Impact labels are estimates. "Critical" and "2-10x improvement" are prioritization aids, not measurements of your app.
• Framework assumptions. Some rules assume Next.js App Router or React Server Components. Check the rule before applying it to a different stack.
• Optimization can backfire. Memoization, dynamic imports, and caching add complexity. Measure after the change.
• The skill is guidance for an agent, not an enforced compiler. A host can ignore it.

Verify it yourself

1. Clone at the pinned commit and count the rule IDs in SKILL.md. Compare that to the README claim.
2. Read three rules in full, including the incorrect and correct examples. Check whether the example matches your React version.
3. Confirm the license declaration in SKILL.md and note the missing root license. If you need redistribution rights, ask the maintainer rather than inferring.
4. Apply one rule to a disposable branch and measure before and after with your own profiler. Do not repeat the impact label as a result.
5. Check whether the rule depends on Next.js. If you are on plain React, skip it or adapt it.

Review transparency

This page is an original guide. It does not reproduce the 70 rule files.

Related

• Web Performance Audit — measure before and after
• Taste-Skill — visual direction, a different job
• React Rules — editor rules, not a skill
• Next.js Rules — framework conventions
• Code Review and Quality — review the change, including performance claims