iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In the Next.js App Router, pages and layouts are Server Components by default. Use a Client Component where an interface needs browser capabilities—such as state, event handlers, effects, or browser APIs—and keep that boundary close to the interaction. The two are not competing ways to render an entire page: they can be composed so server-prepared content surrounds a focused interactive component.
What the two component types mean
Think of a component tree as work divided across a server boundary. Server Components run on the server and can contribute rendered output to the response. A Client Component marks a module subtree that needs client-side JavaScript and browser behavior. The boundary is about execution environment and capabilities, not whether a page is “static” or “dynamic.”
Server-rendered components can be refreshed on the server, and Client Components can appear on routes that are prerendered. Those labels also are not shorthand for server-side rendering versus client-side rendering. In the App Router, the useful question is: which part of this interface actually needs to run in the browser?
Choose by capability, not by page type
| Need | Natural fit |
|---|---|
| Fetch data near its source, use server-only credentials or query logic, or render noninteractive content | Server Component |
| Own state, handle events, use effects or browser APIs, or use client interaction APIs | Client Component |
| Combine server-prepared content with a small interactive control | Server Component for the content; Client Component for the control |
For an official overview, see the Next.js Server and Client Components guide and React’s references for Server Components and the ‘use client’ directive.
#1 Best Overall
What happens when a route first loads
- The server renders Server Components into the React Server Component Payload (RSC Payload).
- Next.js uses the Client Components and RSC Payload to prerender HTML for the route.
- The browser can display that HTML as a noninteractive preview, then reconcile the page using the RSC Payload.
- Client Components hydrate: the browser attaches their event handlers so the controls become interactive.
That is why “Client Component” does not mean “no initial HTML.” On later navigations, the documented behavior differs: Next.js prefetches and caches the RSC Payload, and Client Components render on the client without server-rendered HTML for that navigation. The Next.js guide describes both paths.
Where to put the client boundary
Place 'use client' in the file that defines an interactive component, rather than marking a large page or layout as client code. For example, a post page can fetch and render its title and body as a Server Component, then pass the data needed by a LikeButton Client Component. The button owns its click handler and local state; the post content does not need to become client code.
Rank #2
Likewise, if a mostly static navigation has one interactive search box, make the search component client-side and leave the logo and surrounding layout on the server. Next.js recommends keeping the directive on files that define interactive components.
The directive changes the module graph
'use client' establishes a boundary in the module dependency graph. The marked module and the modules it imports join the client subtree, so placing the directive high in the application can pull more code into the client bundle. It does not need to appear in every descendant file.
The module graph is distinct from the rendered component tree. A Server Component can render a Client Component and pass server-rendered content to it as children or another prop. The client module must not import and invoke that Server Component itself. This lets an interactive wrapper surround content prepared on the server. See React’s ‘use client’ reference for the boundary model.
How to structure data fetching and interaction
- Keep server-owned work on the server. Fetch the data and render the content in a page, layout, or other Server Component when it benefits from server access.
- Identify the exact interaction. Put state, event handlers, effects, browser APIs, or client-only hooks in the component that needs them.
- Pass only what the client needs. Props crossing from a Server Component to a Client Component must be serializable. Pass the required data or rendered content, rather than making the client component import server-only logic.
- Check the current data behavior. In the current Next.js App Router guide, identical
fetchrequests in a React component tree are memoized by default, but requests are not cached by default and can block rendering until they finish. Use the framework’s caching options or Suspense-based streaming when the desired behavior calls for them.
Server execution can keep database credentials and query logic out of the client bundle, but it does not replace security controls. Authenticate users and authorize requests before returning data or performing an operation. For framework-specific details, consult the current Next.js data-fetching guide.
When a Server Component reaches a limit
- It cannot own browser interaction. Server Components cannot define event handlers such as
onClick, useuseState, or own persistent component state. Put those capabilities in a Client Component. - Its client-bound props must be serializable. Keep the boundary’s data in forms React supports crossing it.
- Some third-party widgets need a wrapper. If a client-only package does not mark its own client requirement, wrap its use in a small Client Component.
- Providers can be client-side without making the whole tree client-side. A Server Component can render a provider imported from a Client Component module. Next.js recommends placing providers as deep as practical to preserve opportunities for static optimization.
Do not confuse Server Components with Server Functions
There is no directive for defining a Server Component. 'use server' marks Server Functions: asynchronous server-side functions that client code can call. They are designed for mutations, not recommended as a data-fetching mechanism. Treat their arguments as untrusted, and authenticate and authorize mutations on the server. See React’s ‘use server’ reference.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteQuick Recap
A compact decision rule
- Start with a Server Component for App Router pages and layouts.
- Move only the functionality that needs browser capabilities into a Client Component.
- Compose the two: keep data access and noninteractive content server-side, and pass serializable props or rendered children across the boundary.
- Use caching and streaming intentionally; server-side fetching alone does not determine either behavior.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
