When to keep components on server in NextJS - Deep Dive

Overview - When to keep components on server

What is it?

In Next.js, components can run either on the server or the client. Keeping components on the server means they render on the server before sending HTML to the browser. This approach helps with faster page loads and better SEO because the browser gets ready content immediately. Server components do not include browser-only code like event handlers or state hooks.

Why it matters

Keeping components on the server improves user experience by delivering fully rendered pages quickly, especially on slow networks or devices. Without server components, users might see blank screens or loading spinners while JavaScript loads and runs. It also helps search engines understand your content better, improving your site's visibility. This balance between server and client components is key to building fast, scalable web apps.

Where it fits

Before learning this, you should understand React components and basic Next.js routing. After this, you can explore client components, React hooks, and advanced data fetching strategies. This topic fits in the middle of mastering Next.js app architecture and performance optimization.

Mental Model

Core Idea

Server components render UI on the server to send ready HTML, while client components run in the browser for interactivity.

Think of it like...

It's like ordering a meal at a restaurant: server components are the kitchen preparing the dish before you arrive, so it's ready to eat immediately; client components are like adding your own toppings or sauces at the table to customize the meal.

┌───────────────┐       ┌───────────────┐
│ Server        │       │ Client        │
│ (Server Comp) │──────▶│ (Client Comp) │
│ Renders HTML  │       │ Handles Events│
│ Sends to     │       │ Runs in Browser│
│ Browser      │       │               │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What are Server Components

Concept: Introduce the idea that some components run only on the server in Next.js.

Server components generate HTML on the server and send it to the browser. They do not include JavaScript for interactivity. This means they can fetch data directly from databases or APIs without exposing secrets to the client.

Result

You get fast-loading pages with content already visible when the browser receives the HTML.

Understanding server components helps you see how Next.js can deliver content quickly without waiting for client-side JavaScript.

2

Foundation

Difference Between Server and Client Components

Concept: Explain how server components differ from client components in behavior and usage.

Client components run in the browser and can handle user interactions like clicks or typing. Server components cannot do this because they run before the page reaches the browser. Next.js lets you mix both types to balance speed and interactivity.

Result

You know when to use each type: server components for static or data-heavy parts, client components for interactive UI.

Knowing this difference prevents mixing incompatible code and helps optimize app performance.

3

Intermediate

When to Use Server Components

🤔Before reading on: do you think server components should be used for interactive UI or static content? Commit to your answer.

Concept: Identify scenarios where server components are the best choice.

Use server components for parts of the page that don't need user interaction, like headers, footers, or data lists. They are great for fetching data securely and rendering it immediately. Avoid putting buttons or forms that need client-side events here.

Result

Your app loads faster and uses less client JavaScript, improving user experience.

Understanding when to keep components on the server helps you write efficient, secure, and fast web pages.

4

Intermediate

How Server Components Fetch Data

🤔Before reading on: do you think server components fetch data on the client or server? Commit to your answer.

Concept: Explain data fetching in server components and its benefits.

Server components can fetch data directly during rendering on the server. This means no extra network requests from the browser after page load. You can safely use server-only secrets or APIs here. This reduces client bundle size and speeds up rendering.

Result

Pages show data immediately without loading spinners or delays.

Knowing this clarifies why server components improve performance and security.

5

Intermediate

Mixing Server and Client Components

🤔Before reading on: do you think server components can include client components inside them? Commit to your answer.

Concept: Show how to combine server and client components in Next.js apps.

Server components can import client components to add interactivity where needed. For example, a server-rendered product list can include client components for 'Add to Cart' buttons. This lets you keep most UI fast and static, while enabling dynamic parts.

Result

You build apps that are both fast and interactive without loading unnecessary JavaScript everywhere.

Understanding this composition pattern is key to mastering Next.js app architecture.

6

Advanced

Limitations of Server Components

🤔Before reading on: do you think server components can handle browser events like clicks? Commit to your answer.

Concept: Explain what server components cannot do and why.

Server components cannot handle browser events, use React state, or access browser APIs like localStorage. They also cannot run effects or timers. This is because they render once on the server and do not exist in the browser runtime.

Result

You avoid bugs caused by trying to use client-only features in server components.

Knowing these limits helps you decide which parts of your UI must be client components.

7

Expert

Performance and Security Benefits Deep Dive

🤔Before reading on: do you think server components reduce client JavaScript bundle size? Commit to your answer.

Concept: Explore how server components improve app performance and security in production.

By rendering on the server, these components reduce the JavaScript sent to the browser, lowering load times and memory use. They also keep sensitive data and API keys hidden on the server, preventing leaks. This design supports scalable apps with better SEO and accessibility.

Result

Your production app is faster, safer, and easier to maintain.

Understanding these benefits explains why Next.js invested in server components as a core feature.

Under the Hood

Server components run in a Node.js environment during the server-side rendering phase. They execute React code to produce HTML strings without including client-side JavaScript. When the server sends the HTML to the browser, React hydrates only the client components that need interactivity. This split rendering reduces client bundle size and speeds up initial load.

Why designed this way?

Next.js designed server components to solve slow page loads and heavy client bundles common in single-page apps. By moving static and data-fetching UI to the server, apps become faster and more SEO-friendly. Alternatives like full client rendering or static generation either hurt performance or flexibility, so server components offer a balanced solution.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Server        │       │ Server        │       │ Client        │
│ (Node.js)    │──────▶│ Render HTML   │──────▶│ Hydrate UI    │
│ Runs React   │       │ Send to       │       │ Run Client    │
│ Server Comps │       │ Browser       │       │ Components   │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do server components handle user clicks directly? Commit yes or no.

Common Belief: Server components can handle user interactions like clicks and form inputs.

Reality: Server components cannot handle browser events because they run only on the server before the page loads.

Why it matters: Trying to add event handlers in server components causes errors or non-responsive UI.

Quick: Do server components send JavaScript to the browser? Commit yes or no.

Common Belief: Server components send JavaScript code to the browser just like client components.

Reality: Server components only send HTML to the browser, no JavaScript is included for them.

Why it matters: Misunderstanding this leads to confusion about why some UI parts are not interactive.

Quick: Can server components access browser APIs like localStorage? Commit yes or no.

Common Belief: Server components can use browser APIs because they are React components.

Reality: Server components run on the server and cannot access browser-only APIs.

Why it matters: Using browser APIs in server components causes runtime errors and broken pages.

Quick: Do server components always improve performance? Commit yes or no.

Common Belief: Using server components always makes the app faster.

Reality: Server components improve performance only when used correctly; overusing them for interactive UI can hurt UX.

Why it matters: Misusing server components can lead to slow interactivity and poor user experience.

Expert Zone

1

Server components can reduce client bundle size dramatically, but over-splitting can increase server load and latency.

2

Data fetching in server components can be synchronous, simplifying code compared to client-side async fetching.

3

Server components enable better security by keeping secrets and API keys on the server, invisible to clients.

When NOT to use

Avoid server components for UI that requires frequent user interaction, animations, or browser APIs. Use client components or hybrid approaches instead. For highly dynamic pages, consider client-side rendering or incremental static regeneration.

Production Patterns

In production, developers use server components for layout, navigation, and data-heavy lists, while client components handle forms, buttons, and real-time updates. This pattern balances speed and interactivity, improving SEO and user experience.

Connections

Progressive Enhancement

Server components build on the idea of delivering basic content first, then adding interactivity.

Understanding server components helps grasp how web apps can load usable content quickly and enhance it progressively.

Microservices Architecture

Server components separate concerns like microservices separate backend logic.

Knowing this connection clarifies how modular design improves scalability and maintainability.

Print Publishing Workflow

Like preparing a book's pages before printing, server components prepare HTML before sending to the browser.

This cross-domain link shows how pre-processing content improves final delivery quality.

Common Pitfalls

#1 Trying to add onClick handlers inside server components.

Wrong approach:

export default function Header() {
return ;
}

Correct approach:

import ClientButton from './ClientButton';
export default function Header() {
return ;
}

// ClientButton is a client component with onClick handler

Root cause:

Confusing server components with client components and expecting browser event handling on the server.

#2 Fetching data inside client components that could be done on the server.

Wrong approach:

function ProductList() {
const [products, setProducts] = useState([]);
useEffect(() => {
fetch('/api/products').then(res => res.json()).then(setProducts);
}, []);
return {products.map(p => {p.name})};
}

Correct approach:

export default async function ProductList() {
const products = await fetchProductsFromDB();
return {products.map(p => {p.name})};
}

Root cause:

Not leveraging server components for data fetching leads to slower page loads and more client JavaScript.

#3 Using browser-only APIs like localStorage in server components.

Wrong approach:

export default function UserGreeting() {
const name = localStorage.getItem('name');
return Hello, {name};
}

Correct approach:

import ClientGreeting from './ClientGreeting';
export default function UserGreeting() {
return ;
}

// ClientGreeting uses localStorage safely in the browser

Root cause:

Misunderstanding the environment where server components run causes runtime errors.

Key Takeaways

Server components in Next.js render UI on the server and send ready HTML to the browser, improving load speed and SEO.

They cannot handle browser events or use client-only features, so interactive parts must be client components.

Using server components for static or data-heavy UI reduces client JavaScript and enhances security by hiding secrets.

Mixing server and client components lets you build fast, interactive apps by balancing rendering responsibilities.

Understanding when and how to use server components is key to mastering modern Next.js app performance and architecture.

Practice

1. Which of the following is the best reason to keep a component as a server component in Next.js?

easy

A. It requires frequent updates based on user interaction.

B. It needs to handle user clicks and input events.

C. It fetches data securely and renders static content.

D. It uses browser-only APIs like localStorage.

Solution

1. Step 1: Understand server component purpose

   Server components run on the server and are ideal for static content and secure data fetching.

2. Step 2: Identify interactive needs

   Components that handle user clicks or browser APIs must be client components, not server components.

3. Final Answer:

   It fetches data securely and renders static content. -> Option C

4. Quick Check:

   Server components = static + secure data [OK]

Hint: Server components = static or secure data only [OK]

Common Mistakes:

• Choosing server component for interactive UI
• Using browser APIs in server components
• Thinking server components handle events

2. Which syntax correctly forces static rendering for a server component in Next.js 14+?

easy

A. export const dynamic = 'force-static';

B. export const runtime = 'edge';

C. export const dynamic = 'force-dynamic';

D. export const client = true;

Solution

1. Step 1: Recall server component syntax

   Server components can be forced static with export const dynamic = 'force-static';.

2. Step 2: Differentiate other options

   export const dynamic = 'force-dynamic'; (dynamic = 'force-dynamic') forces dynamic rendering, B (runtime = 'edge') sets edge runtime without forcing static, D is invalid syntax.

3. Final Answer:

   export const dynamic = 'force-static'; -> Option A

4. Quick Check:

   Force static = server component [OK]

Hint: Use 'force-static' to keep component server-only [OK]

Common Mistakes:

• Confusing client directive with server component
• Using 'force-dynamic' for server-only components
• Mixing runtime and dynamic exports

3. Consider this Next.js server component code snippet:

export default function Greeting() {
  const name = fetchNameFromDB();
  return <h1>Hello, {name}!</h1>;
}

What will be the output rendered in the browser?

medium

A. <h1>Hello, [name from DB]!</h1>

B. Error: fetchNameFromDB is not defined

C. <h1>Hello, undefined!</h1>

D. Nothing renders because server components cannot fetch data

Solution

1. Step 1: Understand server component data fetching

   Server components can fetch data directly on the server before rendering.

2. Step 2: Analyze the code behavior

   The function fetchNameFromDB() is not defined in the snippet, so this will cause a runtime error.

3. Final Answer:

   Error: fetchNameFromDB is not defined -> Option B

4. Quick Check:

   Undefined functions cause errors [OK]

Hint: Undefined functions cause errors in server components [OK]

Common Mistakes:

• Assuming fetchNameFromDB is defined
• Thinking server components can't fetch data
• Confusing client-side data fetching with server

4. You have a Next.js component that fetches user data and also handles a button click event. You mistakenly keep it as a server component. What error or issue will you face?

medium

A. The component will render twice causing performance issues.

B. The component will throw a syntax error at build time.

C. The data fetching will fail because server components cannot fetch data.

D. The button click event will not work because server components cannot handle client events.

Solution

1. Step 1: Understand event handling in Next.js components

   Only client components can handle browser events like button clicks.

2. Step 2: Identify the problem with server components

   Server components run on the server and cannot respond to client-side events, so the button click won't work.

3. Final Answer:

   The button click event will not work because server components cannot handle client events. -> Option D

4. Quick Check:

   Server components = no client events [OK]

Hint: Client events need client components [OK]

Common Mistakes:

• Expecting server components to handle clicks
• Thinking server components cause syntax errors
• Confusing data fetching ability

5. You want to build a Next.js page that shows a list of blog posts fetched from a database and includes a search box that filters posts as the user types. How should you split components between server and client?

hard

A. Keep the blog list as a server component and the search box as a client component.

B. Make both blog list and search box client components for interactivity.

C. Make both blog list and search box server components for performance.

D. Keep the search box server component and blog list client component.

Solution

1. Step 1: Identify static and interactive parts

   The blog list is static content fetched from the database, suitable for server components.

2. Step 2: Identify interactive UI needs

   The search box needs to respond to user typing, so it must be a client component.

3. Step 3: Combine components properly

   Use server component for data fetching and rendering list, client component for search input and filtering.

4. Final Answer:

   Keep the blog list as a server component and the search box as a client component. -> Option A

5. Quick Check:

   Static data = server, interactive UI = client [OK]

Hint: Static content server, interactive UI client [OK]

Common Mistakes:

• Making everything client component unnecessarily
• Trying to handle user input in server component
• Mixing up which part fetches data