Server Components mean "less JavaScript" — but draw the boundary wrong and bugs get easier too. The split we use in production.
Server by default
In the App Router every component is a Server Component unless you say otherwise. That means data fetching can live inside the component and ship zero JavaScript to the client. The rule is simple: if it needs no interaction (state, events, effects), keep it on the server.
Push the "use client" boundary down
The most common mistake we see is marking a whole page "use client". Instead, move only the genuinely interactive leaf components to the client. The lower the boundary, the smaller the bundle that reaches the browser.
Data and caching
Fetch data straight from the source in a Server Component and set the cache strategy at the route-segment level. Wiring fetch revalidate, static generation and ISR without tangling them improves both speed and cost on most enterprise sites.
Where it is the wrong tool
Server Components are not a cure-all. For instant, heavily interactive UIs (canvas, drag-and-drop, live charts) the client is still king. Good architecture places both, peacefully, in the same tree.
