vercel-react-best-practices
Vercel React Best Practices
Repository-maintained React and Next.js guidance adapted from Vercel's rules. Use it to address a concrete performance mechanism in the requested work, not to apply every listed pattern across an application.
Establish relevance before optimizing
Identify the affected path, realistic workload, and avoidable cost: a dependency waterfall, repeated request, excessive bundle, expensive render, or hot computation. Support that mechanism with code and usage evidence or a representative trace/profile. A rule match or an impact label alone does not justify a change.
Preserve the user's scope, existing architecture, and correctness contracts. Prefer an existing facility or direct code change before adding a library, cache, or abstraction. Leave already-adequate code alone when the proposed optimization has no meaningful expected benefit. Correctness and security obligations do not depend on proving a performance gain.
Measure before and after when making a performance claim, using comparable workloads and conditions. If measurement is unavailable, explain the supported mechanism and label the benefit as expected or unverified. Do not turn example timings, percentages, or impact ratings into measured results for the user's application.
Dependencies and cache ownership
SWR, better-all, LRU caches, and memoization are conditional options. Reuse the project's data-fetching, scheduling, or caching facilities when they meet the need. Add a dependency only when a demonstrated requirement justifies its maintenance and runtime cost; an example import is not an instruction to install it.
Before adding a cache, establish repeated work, suitable key identity, the owner and lifetime, acceptable staleness, invalidation, memory bounds, and any user or tenant isolation required by the data. Choose the narrowest useful scope. Do not cache mutable or authorization-dependent results without preserving those contracts.