Does using 'use client' ensure that the component only renders on the client?

No, 'use client' does not limit rendering to the client—it marks a boundary where JavaScript is bundled for client-side hydration, but the component still renders on the server to generate initial HTML

Using 'use client' in Next.js does NOT mean the component only renders on the client. This is a common misconception. In reality, all components—both Server Components and Client Components—render on the server to generate the initial HTML that users see. The 'use client' directive serves a different purpose: it creates a boundary between server and client execution, marking where client-side JavaScript should be bundled and hydrated after the server-rendered HTML is delivered. Components with 'use client' still run on the server during the initial render, but they also ship JavaScript to the client to become interactive.

What 'use client' Actually Does

1
Creates a client boundary: When you add 'use client' at the top of a file, it tells Next.js that this component and its imports are part of the client bundle and will be hydrated in the browser.
2
Server rendering still happens: Client Components are still rendered on the server during the initial page load to generate HTML, ensuring fast First Contentful Paint and SEO benefits.
3
JavaScript ships to client: After the HTML is delivered, the JavaScript for Client Components is downloaded and executed to hydrate the page and add interactivity.
4
State and effects become available: Only Client Components can use React hooks like useState, useEffect, and browser APIs because they run in the browser after hydration.

Example: Client Component Still Renders on Server

When a request arrives for a page containing a Client Component, the sequence is: First, Next.js renders the entire component tree on the server, including all Client Components. This produces the initial HTML that's sent to the browser. After the HTML loads, React hydrates the page—this means it re-runs the Client Components in the browser, attaches event handlers, and makes the UI interactive. So Client Components execute twice: once on the server (to generate HTML) and once on the client (to become interactive). The 'use client' directive didn't prevent server execution; it simply flagged that this component needs the second client-side pass.

How This Differs from React Tradition

1
Traditional React (without SSR): Components only render in the browser. No server execution occurs.
2
Traditional React with SSR: Both server and client render phases exist, similar to Next.js but requiring manual setup.
3
Next.js App Router: Server rendering is automatic and mandatory for all components during initial page load—there's no opt-out.
4
The 'use client' directive doesn't control where rendering happens; it controls whether JavaScript is sent to the client.

Dynamic Imports with SSR: false - The Exception

Next.js's design of rendering all components on the server is intentional and crucial for performance. By pre-rendering Client Components on the server, users see complete HTML immediately, even before JavaScript loads. This gives you the interactivity of Client Components with the performance benefits of server rendering. If 'use client' prevented server rendering, pages would display blank shells until JavaScript downloaded and executed, hurting both perceived performance and SEO. The current model offers the best of both worlds: fast initial paint plus rich interactivity.

Practical Implications

1
Server-side code safety: Even in Client Components, code that accesses server-only APIs (databases, file system) will execute on the server. Ensure you conditionally access browser APIs or use useEffect.
2
Hydration mismatches: Since components render twice, any differences between server and client output cause React warnings. Use useEffect for browser-specific code or suppressHydrationWarning when necessary.
3
Bundle size: All code inside Client Components and their imports is included in the client bundle, even if it also runs on the server. Use 'server-only' package to prevent accidental exposure of server code.
4
Performance: Heavy components that don't need immediate interactivity can use dynamic imports with ssr: false to reduce server load and initial bundle size.

Difficulty: 5/10

Topics: client components, server rendering, nextjs app router

Scenario Questions

0-2 years experience

1
If you add 'use client' at the top of a component file, what will happen when that page is requested directly via its URL?
2
How would you modify a simple Next.js page that currently renders a list of items on the server so that the list is fetched client‑side using 'use client'?

2-5 years experience

1
You have a page that mixes server‑only data fetching with a UI component that needs browser APIs. After adding 'use client' to the component, the page fails to render. What could be causing the failure?
2
Explain why a component marked with 'use client' might still cause server‑side code to run, and how you would debug it.

5-8 years experience

1
In a large Next.js application, you need to decide whether to convert an existing server component into a client component. What trade‑offs do you consider regarding bundle size, SEO, and data fetching?
2
A performance audit shows that a client component marked with 'use client' is being rendered on the server during SSR. How would you investigate and fix this issue at the component boundary level?

8+ years experience

1
Your organization is migrating a monolithic Next.js 12 codebase to the app router with client/server components. How would you create a migration strategy that ensures critical pages remain SEO‑friendly while progressively adopting 'use client'?
2
Discuss the long‑term maintenance implications of over‑using 'use client' across many components in a shared component library. How would you enforce guidelines to balance developer ergonomics and bundle bloat?

Follow-up Questions

❓Can you walk me through the steps you’d take to verify where the component is being rendered?
❓What impact does this have on the page’s initial load time?
❓How would you communicate these decisions to other teams?