Choose Server or Client Components in Next.js by Data, Not Habit

A practical approach

Step 1

Start with a Server Component and add 'use client' only when the component needs state, events, effects or browser-only APIs.

Step 2

Fetch data in Server Components close to where it is used, and pass only the serialisable props a client component needs.

Step 3

Keep client components small: a search box, a toggle or a chart, rather than the whole page.

Step 4

Pass server-rendered content into client components as children when an interactive wrapper must contain static content.

Step 5

Never import secrets, database clients or server-only modules into a file marked 'use client'; use the server-only package to make such mistakes fail at build time.

Worked example

A course detail page was marked 'use client' because it contained one 'Add to wishlist' button. The whole page, including a long syllabus and its data-fetching code, shipped as JavaScript, and the page fetched course data again in the browser. Moving the page back to a Server Component and extracting a WishlistButton client component cut the page's JavaScript significantly and removed the second request.

A mistake to avoid

Do not pass large objects or functions from Server to Client Components. Props crossing that boundary must be serialisable, and large payloads are embedded in the HTML. Send the few fields the client component actually uses.

Try it yourself

Open a Next.js App Router project and list every file containing 'use client'. For each, note the interactive feature that requires it. Try to move one large page or layout back to the server by extracting its interactive part.

Your implementation checklist

• Components are Server Components unless they need interactivity
• Client components are small and close to the leaves
• Only serialisable, minimal props cross the boundary
• Server-only code cannot be imported into client files
• Data is fetched once, on the server, where possible