How to Choose Server vs Client Components in Next.js: Practical Examples

Why choosing between Server and Client Components matters

In Next.js 13+, the distinction between Server Components and Client Components directly affects performance, scalability, and user experience. A web app with a smooth 150ms first render usually comes from picking the right component type.

The basic distinction

• Server Components: run on the server, no DOM, no hooks like useState/useEffect. Ideal for data processing logic, API calls, and static content rendering.
• Client Components: run in the browser, support hooks, ideal for interactive UI, forms, and client-side logic.

Real-world examples from a production web app

Case 1: Optimizing render for a dashboard page

In a booking management app, the dashboard displays 30+ realtime metrics. I used Server Components to fetch data from the backend API, then passed it down to Client Components for rendering. Result: 40% faster first render compared to using Client Components everywhere.

Measuring bundle size before/after

• Before: 2.1MB (including data processing logic inside Client Components)
• After: 1.3MB (data processing moved to Server Components)

Case 2: Bugs from overusing 'use client'

When I marked a chart component with 'use client', a hydration mismatch occurred because the server-rendered output differed from the client render. Result: broken UI visible to users.

Common mistakes when overusing 'use client'

1. Hydration mismatch

When the server-rendered component differs from the client-rendered one:

// Server Component
function Chart() {
  return <div>Data chart</div>;
}

// Client Component (misused)
'use client';
function Chart() {
  useEffect(() => {
    fetch('/api/data');
  }, []);
  return <div>Data chart</div>;
}

2. Unnecessary bundle size growth

Marking a non-interactive component with 'use client' pulls all React hooks and client-side logic into the bundle:

'use client';
function StaticContent() {
  return <div>This is static content</div>;
}

3. Harder maintenance

Too many unnecessary 'use client' markers make the codebase complex:

'use client';
function UserProfile({ user }) {
  const [isEditing, setIsEditing] = useState(false);
  return (
    <div>
      {isEditing ? <EditForm /> : <DisplayInfo />}
    </div>
  );
}

How to measure bundle size before/after

Supporting tools

• Webpack Bundle Analyzer: analyze each component in the bundle.
• Next.js built-in: run the build with the analyzer to see the report.
• Lighthouse: measure performance and bundle size.

Measurement examples

• Dashboard page — Before: 2.1MB (including 0.8MB of data processing logic). After: 1.3MB (0.8MB moved to Server Components).
• Product detail page — Before: 1.8MB (including 0.5MB of hooks and client-side logic). After: 1.2MB (only 0.2MB of necessary hooks kept).

Frequently asked questions

When should I use 'use client'?

Use it when the component needs user interaction (forms, buttons, animations) or hooks like useState/useEffect. Examples: login forms, dynamic data displays.

How do I avoid hydration mismatch errors?

Make sure the server-rendered and client-rendered components match, and avoid unnecessary hooks in Server Components.

Should I use Server Components for everything?

No. Server Components do not support hooks or user interaction. Use them for heavy data processing or static content rendering.

How do I measure bundle size effectively?

Use Webpack Bundle Analyzer to see how many KB each component takes, combined with Lighthouse for overall performance.

Is there a tool that automatically optimizes bundle size?

No automatic tool exists, but Next.js App Router automatically splits bundles: each page is its own bundle.

Conclusion

Choosing between Server and Client Components affects not only performance but also maintainability and scalability. By analyzing real examples and measuring bundle size, you can optimize your app effectively.