Why We Default to Server Components (and When We Reach for Client Components Instead)

The question "should this be a server component or a client component" comes up constantly on every React project we build now, and the honest default answer is: server, until you have a specific reason it can't be.

Why server is the default

• It ships less JavaScript to the browser, which means faster load times without any extra optimization work.
• It can talk directly to a database or internal service without exposing an API endpoint just to fetch data.
• It renders once, on infrastructure you control, instead of asking every visitor's device to do that work.

When client is the right, specific answer

Interactivity that has to happen in the browser — a click handler, form state, anything using hooks like useState or useEffect — genuinely needs a client component. The mistake isn't using client components; it's marking a whole page or layout as client when only one small piece of it actually needs to be.

The pattern that keeps this clean

Push client components as far down the component tree as possible — a small interactive island inside an otherwise server-rendered page, not the whole page pulled into the client bundle because of one button. This is exactly the discipline we flagged as easy to lose track of in Next.js in production.

The best client component is the smallest one that does the job. Everything around it should stay on the server if it possibly can.

This isn't dogma for its own sake — it's a direct, measurable effect on load time and bundle size, and it's one of the cheapest performance wins available once a team actually pays attention to it, part of the same requirements-first thinking behind any tech stack decision.