Why We Moved Every Client Project to Server Components

When Server Components moved from experimental to default in the App Router, we didn't switch everything overnight. We ran it on one internal tool for two months, watched the bundle size numbers, and only then started defaulting new client projects to it.

The result we didn't expect: it wasn't the performance win that changed how we build, it was the architectural discipline it forced. Marking a component 'use client' became a real decision instead of a reflex, and that alone cut our average client bundle size by nearly a third.

The performance numbers still matter. Time-to-interactive on a typical marketing site dropped by roughly 35% once data fetching moved server-side and we stopped shipping component logic the browser never needed to run.

The trade-off is real, though: debugging is different, and any engineer joining a project has to relearn where state is allowed to live. We now start every project with a one-page internal doc on our client/server boundary conventions, and it's saved us more review comments than any linter rule.

Our advice to teams considering the move: don't migrate for the sake of the pattern. Migrate when you can point to a specific bundle or latency number you want to move, and treat the 'use client' boundary as an architecture decision worth a paragraph in your pull request, not a default.