/2 min read
Server Components Changed How I Think About Performance
React Server Components aren't just faster — they change the architecture of how we build for the web.
When React Server Components first shipped, the conversation was mostly about performance. Less JavaScript sent to the client. Faster page loads. Better Core Web Vitals.
All true. But after building multiple production sites with them, I've realized the bigger shift is architectural.
The old mental model
In a traditional React app, everything runs on the client. Your component fetches data, renders loading states, handles errors, and eventually shows content. The user stares at a spinner while all of this happens.
Server-side rendering (SSR) helped — the first paint was faster — but the component still had to "hydrate" on the client. The same code ran twice. The same data was fetched twice. The bundle still included every component, even the ones that never needed interactivity.
What actually changed
With Server Components, the split is explicit. A component is either a server component or a client component. Server components:
- Run once, on the server, at build time or request time
- Never ship JavaScript to the browser
- Can directly access databases, file systems, and APIs
- Don't need loading states because the data is already there when the page arrives
Client components handle interactivity — forms, animations, state. Everything else stays on the server.
Why this matters in practice
On a recent project, I built a marketing site with animated sections, interactive forms, and dynamic content. The breakdown:
- 12 server components: layout, headers, content sections, footer
- 3 client components: mobile nav toggle, contact form, scroll animation wrapper
The total client-side JavaScript was under 40KB. The page loaded in 600ms on a 3G connection. No spinners, no layout shift, no flash of unstyled content.
With the old approach, every one of those 12 server components would have been in the bundle — adding weight, hydration time, and complexity for zero benefit.
The design implication
Server Components don't just make sites faster. They make the architecture cleaner. You stop asking "how do I load this data on the client?" and start asking "does this even need to be on the client?"
Most of the time, the answer is no.
The performance gains are real, but the clarity is what keeps me building this way. Every component has a clear job and a clear boundary. That's the kind of codebase I want to hand off — and the kind I want to maintain.