5 React Server Components Mistakes I See in Almost Every Codebase

React Server Components are now the default in Next.js. Most teams have adopted them. Most teams are also making the same handful of mistakes.

I've been working with RSC in production for a while now, and these five patterns show up constantly.

1. Putting use client too high in the tree

The most common one. You hit an error, add use client to the nearest component, and move on. Works — but now you've pulled an entire subtree out of server rendering.

// ❌ One button click handler sends 200 lines to the client
'use client'
export function DashboardSection() { ... }

// ✅ Push it to the leaf
export function DashboardSection() {
  return (
    <div>
      <StatsTable />     {/* stays on server */}
      <RestockButton />  {/* 'use client' lives here */}
    </div>
  )
}

Rule of thumb: use client belongs on the smallest component that actually needs interactivity.

2. Sequential awaits when data is independent

This one silently kills your TTFB. If your data sources don't depend on each other, don't fetch them one by one:

// ❌ Total time = 50ms + 200ms + 100ms = 350ms
const user = await getUser()
const stats = await getStats()
const activity = await getActivity()

// ✅ Total time = max(200ms) = 200ms
const [user, stats, activity] = await Promise.all([
  getUser(), getStats(), getActivity()
])

A 2x perf win with one line change.

3. Blocking the entire page on slow data

One slow API call with no Suspense boundary = your user stares at nothing until everything resolves. You've just built SSR circa 2015.

// ✅ Shell renders immediately, analytics loads progressively
export default function Home() {
  return (
    <div>
      <Header />
      <Suspense fallback={<AnalyticsSkeleton />}>
        <AnalyticsWidget />
      </Suspense>
    </div>
  )
}

Move slow, non-critical data behind Suspense. The rest of the page streams instantly.

4. The "popcorn effect" from too many boundaries

The opposite problem. When every small element has its own Suspense boundary, the page fills up with rapid-fire skeleton → content transitions. It feels broken even though technically everything loaded fine.

Group related UI into a single boundary. Users should perceive one coherent loading state per logical section, not 12 independent ones.

5. Not knowing about the RSC security CVEs

Last December, the React team disclosed a series of serious vulnerabilities in RSC (DoS and source code exposure). An incomplete fix led to follow-up CVEs through January 2026.

If you're on React 19, check your version:

• Safe: 19.0.4, 19.1.5, 19.2.4 and above
• Everything before that is vulnerable

Run npm ls react and update if needed. If your app doesn't use a server, you're not affected.

---

RSC is genuinely great once you internalize the server/client boundary model. The mental shift is real, but so are the performance gains — real apps see 30–60% smaller JS bundles after proper adoption.

What's the trickiest RSC issue you've hit in production?