Why Are You Putting 'use client' at the Top? The 5-Minute Guide to Fixing Next.js App Router Bloat

Every developer transitioning to the Next.js App Router encounters this moment. You add an onClick handler or an onChange listener to a component, save the file, and your development server crashes with a familiar error: "You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with 'use client'..."

The instinctive reaction? Scroll right up to line 1 of page.tsx, type 'use client';, and reload. The red error screen disappears instantly. Problem solved, right?

Not quite. By placing 'use client' at the top of your route file, you inadvertently turn your entire page, all child trees, and heavy third-party packages into client-side JavaScript bundles. You just traded away the core performance benefits of React Server Components (RSC) for a quick fix.

As a frontend developer and technical SEO specialist at Pixel Engine Lab, I will explain what 'use client' actually does under the hood and demonstrate how to keep your bundles featherlight.

1. What Does 'use client' Actually Do Under the Hood?

The biggest misconception among frontend teams is assuming that 'use client' means "render this component only in the browser."

It does not. Client Components in Next.js are still pre-rendered to HTML on the server during the initial page request to ensure fast first paints and strong search indexing. What 'use client' actually establishes is a Network Boundary between server-only logic and the client JavaScript runtime:

• Above the boundary: Code executes exclusively on the server. Dependencies, database calls, API keys, and heavy markdown parsers ship 0 KB of JavaScript to the visitor's browser.
• Below the boundary: The component and every single module imported underneath it get packaged into the client-side JavaScript bundle sent across the wire.

When you paste 'use client' at the top of a page layout or route, you push that boundary all the way to the root, effectively opting out of server-side architecture.

2. When Do You Actually Need a Client Component?

Before adding the directive, walk through this quick evaluation checklist to decide whether client-side execution is strictly required:

• Does the component require React state or lifecycle hooks? If you need useState, useReducer, or useEffect, mark only that specific leaf component as a Client Component.
• Does the component bind browser event listeners? User interactions such as onClick, onSubmit, or custom window listeners must run on the client.
• Does the component access browser-only APIs? Interacting directly with window, document, localStorage, or navigator requires the client boundary.

If your component only fetches data, renders HTML, parses text, or applies styles, keep it a Server Component by default.

3. Anti-Pattern vs. Leaf Pattern: What Is the Difference?

Let us look at a common scenario: a blog article that needs an interactive like counter alongside a heavy markdown rendering engine.

Why Is Polluting the Page Root an Anti-Pattern?

// app/blogs/[slug]/page.tsx
'use client'; // ❌ Avoid this: forces the entire page into the client bundle

import { useState } from 'react';
import HeavyMarkdownRenderer from '@/components/HeavyMarkdown'; // 120 KB bundle sent to browser!

export default function BlogPost({ post }: { post: any }) {
  const [likes, setLikes] = useState(0);

  return (
    <article className="prose mx-auto py-10">
      <h1>{post.title}</h1>
      {/* This non-interactive markdown engine is now needlessly compiled on the client */}
      <HeavyMarkdownRenderer content={post.content} />
      
      <button 
        onClick={() => setLikes(likes + 1)}
        className="rounded bg-blue-600 px-4 py-2 text-white"
      >
        Like ({likes})
      </button>
    </article>
  );
}

How Does Pushing 'use client' to the Leaves Solve It?

Extract the interactive button into its own isolated component file. This leaves the heavy markdown parser safely on the server:

// components/LikeButton.tsx
'use client'; // ✅ Interactivity is strictly scoped to this button

import { useState } from 'react';

export default function LikeButton() {
  const [likes, setLikes] = useState(0);

  return (
    <button 
      onClick={() => setLikes(likes + 1)}
      className="rounded bg-blue-600 px-4 py-2 text-white"
    >
      Like ({likes})
    </button>
  );
}

// app/blogs/[slug]/page.tsx
// No 'use client' directive needed: default Server Component
import HeavyMarkdownRenderer from '@/components/HeavyMarkdown';
import LikeButton from '@/components/LikeButton';
import { getBlogPost } from '@/lib/posts';

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getBlogPost(params.slug);

  return (
    <article className="prose mx-auto py-10">
      <h1>{post.title}</h1>
      {/* 0 KB of client JavaScript shipped for this heavy renderer */}
      <HeavyMarkdownRenderer content={post.content} />
      
      {/* Only the tiny button bundle is sent to the browser */}
      <LikeButton />
    </article>
  );
}

4. How Do You Pass Server Components Inside Client Wrappers?

A frequent challenge arises when you need an interactive wrapper—such as a modal dialog, sliding drawer, or an animated container—around heavy, data-driven content. If you import Server Components directly inside a file marked with 'use client', Next.js converts those children into client components as well.

To preserve server rendering, pass Server Components into the Client Component via the children prop:

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

import { useState, ReactNode } from 'react';

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

  return (
    <div className="drawer-wrapper">
      <button onClick={() => setIsOpen(!isOpen)}>
        {isOpen ? 'Close' : 'Open'} Details
      </button>
      {isOpen && <div className="drawer-content">{children}</div>}
    </div>
  );
}

// app/dashboard/page.tsx
// Server Component
import AnimatedDrawer from '@/components/AnimatedDrawer';
import ComplexDataSummary from '@/components/ComplexDataSummary'; // Heavy server-only component

export default function DashboardPage() {
  return (
    <main>
      <h1>Performance Dashboard</h1>
      <AnimatedDrawer>
        {/* ComplexDataSummary renders on the server and ships zero client JS! */}
        <ComplexDataSummary />
      </AnimatedDrawer>
    </main>
  );
}

How Should You Think About 'use client' Moving Forward?

Writing performant Next.js applications comes down to managing your network boundaries. Treat 'use client' like an import expense: push it down your component tree until it wraps only the exact element that requires user input or browser APIs.

At Pixel Engine Lab, we build high-performance web applications and enterprise architectures optimized for Core Web Vitals and search rankings.

Contact our engineering team to review your frontend architecture and streamline your application's production performance.