React Server Components render on the server and send a serialised result to the browser, with no component JavaScript shipped for those parts. Used well, this cuts bundle size on content-heavy pages considerably.
The mental model
Server components run once, on the server, with direct access to data. They cannot hold state or use effects. Client components behave as React always has. The skill is drawing the boundary in the right place.
- Data fetching and formatting belong on the server
- Anything with state, effects or event handlers must be a client component
- Push the boundary as far down the tree as possible
- Pass serialisable props across the boundary only
What genuinely improves
Content-heavy pages ship far less JavaScript, data fetching moves next to the component that needs it, and sensitive logic stays server side.
What does not change
Server components are not a caching strategy and not a substitute for a fast database. A slow query is still slow, and layout shift is still layout shift.
When to adopt
If your application is mostly interactive dashboards, the benefit is modest. If it is marketing pages, catalogues, documentation or articles, the reduction in shipped JavaScript is significant.
The win is not that rendering moved. It is that large parts of the tree no longer ship any JavaScript at all.
Where to start
Take your heaviest page, measure the JavaScript it ships, and convert only the non-interactive parts. Measure again before going further.
