Struggling with “use client” at the top of every Next.js file? Learn why this “client-side contagion” happens and discover three practical solutions, from quick fixes to architectural patterns, to reclaim your server components and boost performance.

So, You’ve ‘use client’-ed Yourself into a Corner. Let’s Fix It.

I remember a late-night performance audit for a new e-commerce client, let’s call them ‘Project Bloom’. Their Time to First Byte (TTFB) was abysmal, and the Lighthouse scores were a sea of red. Our monitoring on the `prod-web-cluster-03` showed the server was barely breaking a sweat, so it wasn’t a resource issue. After an hour of digging, we found it: nearly every single page and layout file in their Next.js app started with 'use client'. A junior dev, trying to use a simple state hook in the navigation bar, had inadvertently turned their entire application into a giant, slow-loading single-page app. It’s an honest mistake, one I see constantly, and it stems from a fundamental misunderstanding of how the new App Router thinks.

The Root of the Problem: The ‘use client’ Contagion

Before we jump into fixes, you need to understand why this happens. In the Next.js App Router world, everything is a React Server Component (RSC) by default. This is great for performance—they render on the server, they can `async/await` data directly, and they send zero JavaScript to the client.

The moment you add 'use client' to the top of a file, you’re creating a boundary. That component, and critically, every component you import into it, becomes part of the client-side JavaScript bundle. If your main `layout.tsx` has 'use client' because you need a theme provider that uses context, you’ve just told Next.js to make your entire application, every page, every component nested inside that layout, a client component. It’s a contagion that spreads down the component tree.

Pro Tip: Stop thinking about “pages” and start thinking about “component trees”. Your job isn’t to make an entire page a client or server component; it’s to push the client-side interactivity as far down the tree—to the leaves—as possible.

Three Ways to Escape ‘use client’ Hell

Alright, enough theory. You’re here because your app is a mess and you need to fix it. Here are three strategies, from a quick patch to a full-blown refactor, that we use at TechResolve.

1. The Quick Fix: Isolate and Delegate with Children

This is the most common and effective pattern you’ll use. Instead of making an entire layout or page a client component just to use one interactive element, keep the parent as a Server Component and pass the interactive part in as a child.

The Bad Way (Contagion):

'use client'; // This infects everything below!

import { useState } from 'react';
import { ExpensiveServerComponent } from './ExpensiveServerComponent';

export default function DashboardLayout({ children }) {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <section>
      <nav>
        <button onClick={() => setIsOpen(!isOpen)}>Toggle Menu</button>
        {/* ... other nav items ... */}
      </nav>
      {/* This component is now forced to be client-side! */}
      <ExpensiveServerComponent />
      {children}
    </section>
  );
}

The Good Way (Isolation):

First, create the small, interactive part as its own Client Component:

// components/InteractiveNavbar.tsx
'use client';

import { useState } from 'react';

export function InteractiveNavbar() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <nav>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle Menu</button>
      {/* ... other nav items ... */}
    </nav>
  );
}

Now, import that into your layout, which can remain a Server Component:

// layout.tsx (This is a Server Component again!)

import { ExpensiveServerComponent } from './ExpensiveServerComponent';
import { InteractiveNavbar } from './components/InteractiveNavbar';

export default function DashboardLayout({ children }) {
  return (
    <section>
      <InteractiveNavbar />
      {/* This renders on the server where it belongs! */}
      <ExpensiveServerComponent />
      {children}
    </section>
  );
}

You’ve successfully quarantined the client-side logic to only the component that needs it.

2. The Permanent Fix: Adopt the Provider Pattern

This is for things like theme providers, analytics context, or session providers that need to wrap your entire application. The naive approach is to put 'use client' on your root layout, which we’ve established is a disaster.

The solution is to create a dedicated client-side “provider” component that takes server-rendered components as `children`.

// providers/theme-provider.tsx
'use client';

import { ThemeProvider as NextThemesProvider } from 'next-themes';

// This is the only file that needs 'use client'
export function ThemeProvider({ children }) {
  return (
    <NextThemesProvider attribute="class" defaultTheme="system" enableSystem>
      {children}
    </NextThemesProvider>
  );
}

Now, in your root `layout.tsx`, you wrap your `children` with this provider. The layout itself stays a Server Component, and it passes its server-rendered children into the client-side provider component’s `children` prop.

// layout.tsx (Root Server Component)
import { ThemeProvider } from './providers/theme-provider';
import { Header } from './Header'; // Another server component
import { Footer } from './Footer'; // And another

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <ThemeProvider>
          <Header />
          <main>{children}</main>
          <Footer />
        </ThemeProvider>
      </body>
    </html>
  );
}

The `Header`, `Footer`, and the `children` (your pages) are all rendered on the server first, and their resulting HTML is passed into the `ThemeProvider`. It’s the best of both worlds.

3. The ‘Nuclear’ Option: The Component Audit

Sometimes the problem is too widespread. You’ve inherited a codebase where 'use client' is sprinkled everywhere without rhyme or reason. In this case, a targeted fix won’t work. You need to take a step back and perform a full audit.

This is what we had to do for ‘Project Bloom’. It’s painful but necessary.

• Analyze: Use the Next.js Bundle Analyzer (`@next/bundle-analyzer`) to visualize what’s ending up in your client bundle. You’ll be shocked at what you find.
• Identify: Go through your entire `app` directory, file by file. Create a simple spreadsheet. Column A: Component Name. Column B: Does it *truly* need state, effects, or browser APIs? (Yes/No).
• Refactor: Based on your audit, aggressively apply patterns 1 and 2. Move client logic into the smallest possible components. Remove every unnecessary 'use client'.
• Verify: Rerun the bundle analyzer. Watch the client bundle size shrink. Monitor your performance metrics and watch your TTFB and LCP improve dramatically.

Warning: This is not a quick task. This is a deliberate effort to pay down technical debt. Block out time for it, and don’t expect to do it in an afternoon. But the performance gains are absolutely worth it.

Final Thoughts: It’s a Mindset Shift

Having most of your pages rendered on the client in Next.js 13+ is absolutely not normal, and it’s a sign that you’re fighting the framework. You’re giving up the primary performance benefits of the App Router.

The key is to change your thinking. Don’t start with 'use client'. Start with everything as a Server Component and only add the client directive when you literally cannot build a feature without a hook or a browser API. When you do, quarantine it immediately. Your users, and your servers, will thank you for it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions