DEV Community: Paweł Sobolewski

React Server and Client Components in Next.js: Understanding the Difference

Paweł Sobolewski — Tue, 30 Dec 2025 23:00:00 +0000

The React team introduced Server Components as an experimental feature in React 18. They allow parts of a React application to render on the server, reducing the JavaScript sent to the client and enabling more efficient data fetching.

Next.js adopted this concept and integrated it into its App Router (introduced in version 13). The framework combines React's server-rendering capabilities with its own routing, data fetching and performance optimizations.

Server Components let developers build apps that are faster, more secure and easier to maintain—while still adding interactivity through Client Components where needed.

What Are Server Components?

Server Components run exclusively on the server—they never execute in the browser and cannot use client-only features like useState, useEffect, or window.

Since they render on the server, they can securely fetch data from databases or APIs and send back only the resulting HTML to the client. This reduces bundle size and improves performance.

Key Characteristics:

Run only on the server
Exclude JavaScript from the client bundle
Fetch data securely without needing API routes
Cannot use React state hooks or browser APIs
Can import Client Components, but Client Components cannot import them

Example:

// This is a Server Component (default)
export default async function ServerComponent() {
  const posts = await fetchPosts();
  return (
    <ul>
      {posts.map(post => <li key={post.id}>{post.title}</li>)}
    </ul>
  );
}

By default, all components in the Next.js App Router (app/ directory) are Server Components, unless specified otherwise.

What Are Client Components?

Client Components are traditional React components that run in the browser. They're necessary when you need interactivity, state, or effects.

To mark a file as a Client Component, add this directive at the top: "use client";

Here's a common misconception: Client Components are still prerendered on the server. During the initial render, Next.js generates HTML for them on the server—just like Server Components. Once the JavaScript bundle loads in the browser, React hydrates these components, attaching event listeners and state to make them interactive.

Example:

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

Important:

Hydration errors occur when the server-rendered HTML doesn't match what React renders in the browser—for example, when using Math.random() or Date.now() during render.
Client Components cannot import Server Components
However, you can pass Server Components as props to Client Components. React renders them on the server and includes them in the client-rendered tree (see below).

Combining Server and Client Components

Next.js's true power lies in combining both component types effectively. You can fetch data on the server, then pass it to a client component for interactive rendering.

Example:

// Server Component
import Counter from "./Counter"; // ✅ allowed (Client Component)

export default async function Page() {
  const user = await fetchUser();
  return (
    <div>
      <h1>Hello, {user.name}</h1>
      <Counter />
    </div>
  );
}

Passing Server Components as Props

While Client Components cannot import Server Components, a Server Component can pass another Server Component as a prop to a Client Component.

This works because the server renders the server-side part before sending it to the browser.

// Server Component A
export function ServerInfo() {
  return <p>Server time: {new Date().toISOString()}</p>;
}

// Client Component
"use client";
export function Wrapper({ info }) {
  return (
    <div className="wrapper">
      <h2>Wrapped content:</h2>
      {info}
    </div>
  );
}

// Server Page
import { ServerInfo } from "./ServerInfo";
import { Wrapper } from "./Wrapper";

export default function Page() {
  return <Wrapper info={<ServerInfo />} />;
}

Here's what happens:

Wrapper is a Client Component.
It does not import ServerInfo directly.
Instead, ServerInfo is rendered on the server and passed as a serialized React node through props.

This pattern is powerful for composition, layout customization, and partial interactivity in server-driven views.

Hydration and Common Pitfalls

Hydration is the process of React attaching interactivity to the static HTML produced by the server.

It’s an essential step — but also a common source of confusion and bugs.

Common Causes of Hydration Errors:

Non-deterministic rendering — e.g., using Math.random(), Date.now(), or random IDs directly in render.
Conditional rendering differences between server and client.
Mismatched props — if server and client data diverge during hydration.

How to Avoid Them:

Use deterministic data in components that render both server- and client-side.
Avoid rendering dynamic values that differ between server and client.
Keep interactivity isolated in small, well-defined Client Components.
Keep dynamic parts in “client only scope”, like useEffect hook

Quick Comparison

Feature	Server Component	Client Component
Execution	Server only	Server prerender + Browser hydration
Can use hooks (`useState`, `useEffect`)	❌	✅
Can fetch data securely	✅	⚠️ via API routes
Imports direction	✅ Can import Client	❌ Cannot import Server
Can receive Server Components as props	✅	✅
Bundle size impact	Minimal	Increases bundle size
SEO	Excellent	Also good (since prerendered)
Typical use	Static content, data fetching	Interactive UI, forms, animations

Conclusion

React introduced the Server/Client component model, giving developers precise control over where and how rendering happens. Next.js enhances this with routing, data fetching, and performance optimizations.

To summarize:

Use Server Components for data-heavy or static content.
Use Client Components for interactivity.
Client Components are prerendered on the server, then hydrated in the browser.
Import flow: Server → Client ✅, Client → Server ❌.
However, Server Components can be passed to Client Components via props ✅.

When used correctly, this architecture makes your app faster, more secure, and easier to maintain—a true win for modern React development.

Next.js Streaming Explained: Faster Rendering vs CSR & SSR

Paweł Sobolewski — Wed, 15 Oct 2025 21:21:46 +0000

Modern web apps need to load fast - users won’t wait for entire pages to render before engaging with content. Traditional methods like client-side rendering often introduce delays, especially when data fetching depends on large JavaScript bundles. Next.js streaming, powered by React Server Components and Suspense, solves this by progressively sending page content to the browser as it becomes ready. The result: faster time-to-first-content and a smoother user experience.

Why Use Streaming in Next.js?

Streaming isn't just another performance optimization - it solves specific problems in modern frontend development. Users today demand immediate feedback, but traditional rendering approaches often create delays that make interfaces feel unresponsive.

By allowing the server to send parts of a page to the browser as they become ready, streaming eliminates waiting for complete page rendering. Users can view and interact with meaningful content almost immediately. This approach not only enhances perceived performance but also eliminates the frustration of watching loading spinners or staring at empty placeholders.

Imagine this scenario: You have a large web page where most content is either static or quickly retrieved. However, one component depends on a slow external API. Without streaming, the entire page would be delayed while waiting for that single request. With streaming, the majority of the page appears immediately, with only the slower component arriving later. For users, this creates a fast, responsive experience, even when certain elements take longer to load.

Next.js Streaming vs Client-Side Rendering (CSR)

At first glance, streaming and client-side rendering seem to share a common goal: delivering content to users quickly without waiting for the entire page to load. However, they solve this problem in fundamentally different ways.

Client-Side Rendering (CSR)

With CSR, the server sends only a minimal HTML shell and a JavaScript bundle. Since client components cannot be asynchronous, they can't effectively fetch data during rendering. Instead, developers must rely on useEffect for any asynchronous operations.

This approach has three major drawbacks:

Larger bundles – more logic and components must be sent to the browser.
Delayed data fetching – network requests can only start after the JavaScript has been downloaded, parsed, executed, and the component reaches the useEffect stage. This significantly delays data retrieval compared to server-side methods.
Tricky security - because data fetching happens on the client, sensitive information like API keys may need to be exposed or handled carefully.

Streaming

Streaming takes the opposite approach. With rendering and data fetching happening on the server, the application can start retrieving data immediately. As soon as any part of the page is ready, it's sent to the browser and displayed - no need to wait for the entire UI. This approach reduces time to first meaningful paint and eliminates the "waterfall" effect common in CSR.

How Next.js Streaming Works with React Server Components

In Next.js, streaming leverages React Server Components and Suspense to progressively send HTML to the browser instead of waiting for the entire page to render.

Here's the process:

Initial render: The server immediately sends HTML for ready-to-display elements (layout, header, placeholders, etc.).
Suspense boundaries: Components requiring slower data (API calls, database queries) are wrapped in special <Suspense /> component, showing fallbacks like spinners or skeletons rather than blocking the entire page.
Progressive hydration: Once data resolves, the server streams the completed HTML for that component, seamlessly replacing the fallback in the browser.
JS hydration (in parallel): Simultaneously, client-side JavaScript gradually hydrates the page to make it fully interactive.

Using the React `use` Hook for Streaming in Next.js

Next.js also enables streaming through the use hook, which lets React components directly unwrap promises inside Client Components.

The common implementation pattern works like this:

A Server Component initiates the async operation and passes the promise as a prop.
A Client Component utilizes the use hook to consume the data, suspending itself until the data is ready.

Why this matters:

With traditional streaming, the streamed component must be a Server Component that fetches data. Client Components, by default, cannot be asynchronous, which prevents them from directly participating in streaming.
The use hook solves this limitation: it enables Client Components to consume promises and suspend. This means you can stream data and immediately add interactivity (such as event handlers and UI state) without needing to split logic between server and client.
This gives developers greater flexibility: data loading still begins early on the server, while the final rendering and interactive elements can reside in Client Components.

Does Next.js Streaming Require JavaScript?

It's important to understand that streaming doesn't eliminate the need for JavaScript in the browser. While the server handles data fetching and initial HTML rendering, the browser still needs JavaScript to replace temporary placeholders - like spinners or skeletons - with the actual content as it arrives.

Without JavaScript, users would only see the static placeholders, preventing the progressive content delivery from functioning, even though the server has already generated this content.

In essence, streaming speeds up content delivery, but JavaScript remains essential for swapping temporary elements with the final rendered components.

Next.js Streaming Example with Code (SSR vs CSR vs Streaming)

Repository link: https://github.com/u11d-com/blog_nextjs-streaming

To demonstrate streaming benefits in a real-world context, I've built a very simple Next.js demo application that fetches and displays a list of funny jokes. This project compares three rendering strategies side by side: traditional Server-Side Rendering (SSR), Client-Side Rendering (CSR), and the newer React Server Components with streaming (with server and client components approaches).

The application features separate pages for each rendering approach:

SSR Page: Renders everything on the server and delivers complete HTML in a single response. Users see content only after the server processes the entire page.
CSR Page: Delivers a minimal HTML shell while JavaScript handles all data fetching on the client side. Users see loading states until data fetching and rendering complete.
Streaming Page: Leverages React Server Components to progressively send UI parts to the browser as they become ready. This allows users to interact with visible content while slower components continue loading.
Streaming Page with use Hook: Uses the React use hook to stream data directly into Client Components. This enables not only progressive rendering but also immediate interactivity, since Client Components can both consume async data and attach event handlers without waiting for a full page load.

The application includes a built-in analytics system that tracks rendering times for each page section, helping visualize the performance differences between SSR, CSR, and streaming approaches.

Event	SSR (ms)	CSR (ms)	STREAMING (ms)	STREAMING WITH USE (ms)
Fetching jokes started	3	281	4	3
Joke list rendered	2451	2545	2255	2418
Page rendered	2722	281	272	285

You can fetch and run the application Yourself, but let’s talk about results and what they mean.

Next.js Performance Benchmark: SSR vs CSR vs Streaming

Our benchmark clearly shows how each rendering strategy differs in data fetching timing and content delivery.

SSR (Server-Side Rendering)

Fetching jokes started: ~3 ms (almost immediately)
Joke list rendered: ~2451 ms
Page rendered: ~2722 ms

Analysis: While data fetching begins instantly, users see nothing until all data is processed. This creates a slower first paint, despite the server's early work.

CSR (Client-Side Rendering)

Fetching jokes started: ~281 ms
Page rendered: ~281 ms (initial skeleton/spinner)
Joke list rendered: ~2545 ms

Analysis: With CSR, data fetching waits for JavaScript to load (~281 ms). Users see a placeholder quickly but wait over 2.5 seconds for actual content.

Important: Larger, more complex pages mean bigger JS bundles that take longer to execute. This delays data fetching even further, increasing time to meaningful content and hurting user experience.

Streaming

Fetching jokes started: ~4 ms
Page rendered: ~272 ms
Joke list rendered: ~2255 ms

Analysis: Streaming offers the best experience: data fetching starts immediately, initial content appears in ~272 ms, and slower components load progressively.

Key advantage over CSR: Streaming doesn't depend on JavaScript bundle size to begin fetching data. This allows even complex pages to start loading meaningful content almost instantly, dramatically improving perceived performance.

Conclusion: Why Streaming is Best for Next.js Performance

Comparing SSR, CSR, and Streaming in Next.js reveals distinct trade-offs for each approach:

SSR begins data fetching immediately on the server, but delivers a slower time-to-first-content for users.
CSR postpones data fetching until after JavaScript bundle execution, with larger pages further extending this delay - resulting in the longest wait for meaningful content.
Streaming offers the best of both worlds: nearly instant data fetching, quick initial content rendering, and progressive component delivery. Because it doesn't depend on bundle size to start loading data, streaming ensures fast perceived performance even with complex pages.

Bottom line: For modern Next.js applications where user experience and speed are priorities, streaming provides the most responsive and scalable solution.

FAQ Section

Frequently Asked Questions (FAQ) about Next.js Streaming

Q: What is streaming in Next.js?

A: Streaming is a rendering technique where the server sends parts of a page to the browser as soon as they’re ready. Instead of waiting for the entire page to render, users see meaningful content almost immediately, improving perceived performance.

Q: How is streaming different from client-side rendering (CSR)?

A: CSR waits until the JavaScript bundle loads before fetching data, delaying meaningful content. Streaming starts data fetching on the server instantly and progressively streams components, making the page feel faster and more responsive.

Q: Does streaming replace SSR (Server-Side Rendering)?

A: No. Streaming builds on SSR by adding progressive delivery. SSR sends a complete page after rendering, while streaming sends it in chunks, letting users see content earlier.

Q: Do I still need JavaScript with streaming?

A: Yes. While the server handles data fetching and initial HTML, JavaScript is required to replace placeholders with the actual streamed content and hydrate the UI for interactivity.

Q: What is the use hook in streaming?

A: The use hook allows React Client Components to directly consume promises. This means you can stream data into interactive Client Components without splitting logic between server and client.

Q: When should I use streaming in my Next.js app?

A: Use streaming when your page contains a mix of fast-loading and slow-loading content. It ensures users can interact with available content immediately while slower components continue to load in the background.

SSG, ISR, SSR, CSR: which strategy should I use in my Next.js e-commerce platform?

Paweł Sobolewski — Mon, 29 Sep 2025 09:53:02 +0000

Introduction

In today's evolving web development landscape, selecting the right rendering strategy is vital for creating fast, scalable, and user-friendly applications. Next.js, a leading React framework, offers four powerful major rendering options: Static Site Generation (SSG), Incremental Static Regeneration (ISR), Server-Side Rendering (SSR), and Client-Side Rendering (CSR). Each approach comes with its own set of features and trade-offs.

For e-commerce platforms, where performance, SEO, and content freshness directly impact business success, choosing the optimal rendering method is critical. This choice can dramatically affect page load speeds, search engine visibility, and—by extension—user satisfaction and conversion rates.

With Next.js 13, the introduction of the App Router brings a new routing paradigm centered on React Server Components. This update offers enhanced flexibility and finer control over rendering strategies. While SSG, ISR, SSR, and CSR remain as core concepts, their implementation now relies primarily on caching behavior and component-level dynamic data fetching.

In this article, we explore how SSG, ISR, SSR, and CSR function in Next.js 13 and later versions. We'll examine their strengths and limitations to help you make informed decisions when building or improving e-commerce platforms.

1. Static Rendering vs Dynamic Rendering

In Next.js, page rendering depends on when and how HTML is generated: either at build time (static) or at request time (dynamic). With the App Router, Next.js automatically selects the optimal rendering strategy based on how components fetch and handle data.

By default, Next.js uses static rendering when possible to maximize performance and scalability. For pages requiring fresh or user-specific data, it switches to dynamic rendering.

⚙️ What triggers dynamic rendering?

Next.js switches to dynamic rendering in these major cases:

Condition	Effect
`fetch()` with `cache: 'no-store'`	Forces Server-Side Rendering (SSR) — no caching
`fetch()` with `next: { revalidate: 0 }`	Also disables caching — triggers SSR
`export const dynamic = 'force-dynamic'`	Explicitly instructs Next.js to use SSR
Use of dynamic functions like `cookies()`, `headers()`	Makes page request-specific — disables static rendering
Use `params` prop without `generateStaticParams()` and proper `dynamicParams()` settings	`generateStaticParams()` allows pre-rendering of specific parameter values at build time, while remaining paths will be handled via SSR or return a 404, depending on the `dynamicParams()` configuration

2. Static Site Generation (SSG)

Static Site Generation (SSG) generates pages at build time and serves them as static HTML files. This approach delivers exceptionally fast load times, high reliability, and excellent scalability because content is prepared before any user requests and can be efficiently distributed through CDNs.

✅ Key Advantages

⚡ Performance: Pages load instantly from CDN or edge cache.
🔒 Stability: No server-side rendering needed, minimizing potential failures.
🔍 SEO-ready: Complete HTML available immediately for search engines.
📈 Scalable: Perfect for high-traffic pages due to pre-rendered content.

⚠️ Limitations

Content stays static between builds, updates requires additional application build.
Not ideal for pages needing real-time updates or personalization.

Given these advantages, ideal candidates for SSG in e-commerce include:

promotional or campaign landing pages,
static marketing and brand content (e.g., about pages, policies, shipping info).

Product listing and details pages can also benefit from SSG when their content updates infrequently.

🛠️ Implementation

Let's examine how to implement a static product details page.

import "./ProductPage.css";

type Product = {
  id: string;
  name: string;
  description: string;
};

const mockProducts: Product[] = [
  { id: "1", name: "T-Shirt", description: "Comfortable cotton t-shirt." },
  { id: "2", name: "Sneakers", description: "Lightweight running shoes." },
  { id: "3", name: "Watch", description: "Elegant analog wristwatch." },
  { id: "4", name: "Backpack", description: "Durable everyday backpack." },
  { id: "5", name: "Sunglasses", description: "Polarized UV protection." },
  { id: "6", name: "Hat", description: "Stylish summer hat." },
  { id: "7", name: "Jacket", description: "Windproof outdoor jacket." },
  { id: "8", name: "Jeans", description: "Slim-fit denim jeans." },
  { id: "9", name: "Scarf", description: "Warm wool scarf." },
  { id: "10", name: "Boots", description: "Waterproof hiking boots." },
];

export const dynamicParams = false;

export async function generateStaticParams() {
  return mockProducts.map((product) => ({
    id: product.id,
  }));
}

export default async function ProductPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;

  const product = mockProducts.find((p) => p.id === id);

  // Since dynamicParams = false, this will never be rendered unless id is valid.
  return (
    <main className="product-page">
      <div className="product-card">
        <h1 className="product-title">{product?.name}</h1>
        <p className="product-description">{product?.description}</p>
        <button className="product-button">Add to cart</button>
      </div>
    </main>
  );
}

app/product/ssg/[id]/page.tsx

🧠 Explanation

In the example above, we use Static Site Generation (SSG) to pre-render individual product pages at build time. Let's explore the key elements of the implementation:

generateStaticParams()

This asynchronous function tells Next.js which dynamic routes to pre-render. In our case, we hardcode 10 mock products, but it could be as well a call to Your database. Result would be the same: only these 10 product pages (e.g., /product/ssg/1, /product/ssg/2, ..., /product/ssg/10) will be built statically.

server
├── app
│   ├── _not-found
│   └── favicon.ico
│   └── product
│          └── ssg
│               └── [id]
│                    └── 1.html
│                    └── 2.html
│                    └── 3.html
│                    └── 4.html
│                    └── 5.html
│                    └── 6.html
│                    └── 7.html
│                    └── 8.html
│                    └── 9.html
│                    └── 10.html

dynamicParams = false

By setting this flag, we explicitly instruct Next.js to return a 404 error for any route that wasn't generated by generateStaticParams().

This means:

/product/ssg/3 → ✅ built at build time
/product/ssg/999 → ❌ will automatically render the 404 page

Although we use the dynamic params prop, pairing it with generateStaticParams() enables complete SSG functionality — eliminating runtime rendering and the need for manual product validation in the component.

3. Incremental Static Regeneration (ISR)

What if our static product pages need frequent updates—daily or weekly? This is where ISR comes into play.

Incremental Static Regeneration (ISR) allows static pages to update in the background after deployment. It combines the performance benefits of Static Site Generation (SSG) with dynamic content updates—all without requiring a full rebuild.

For e-commerce sites where product data changes regularly—such as prices, availability, or descriptions—ISR offers an ideal solution when updates are needed more frequently than full deployments allow.

❓How it works

ISR generates pages at build time (like SSG), but includes a revalidation period. After this period expires, the next user request triggers a background regeneration. The new version is then cached and served to subsequent visitors.

✅ Key Advantages

🧠 Hybrid flexibility: Combines SSG benefits with content freshness.
🔁 On-demand freshness: Updates pages without full redeployment.
🚀 Performance first: Serves pre-rendered static content to most users.
🔧 Control via revalidation: Customisable content staleness thresholds.
🛠️ Programmatic control: Immediate page updates using revalidatePath()—perfect for admin panels or CMS triggers.

⚠️ Limitations

Slightly higher complexity compared to pure SSG.
Regeneration occurs after a stale page request.
Revalidation cannot guarantee real-time consistency across all users.

🛠️ Implementation

Let's modify our previous product details page to implement ISR with hourly updates.

import { notFound } from "next/navigation";

import "./ProductPage.css";

type Product = {
  id: string;
  name: string;
  description: string;
};

const mockProducts: Product[] = [
  { id: "1", name: "T-Shirt", description: "Comfortable cotton t-shirt." },
  { id: "2", name: "Sneakers", description: "Lightweight running shoes." },
  { id: "3", name: "Watch", description: "Elegant analog wristwatch." },
  { id: "4", name: "Backpack", description: "Durable everyday backpack." },
  { id: "5", name: "Sunglasses", description: "Polarized UV protection." },
  { id: "6", name: "Hat", description: "Stylish summer hat." },
  { id: "7", name: "Jacket", description: "Windproof outdoor jacket." },
  { id: "8", name: "Jeans", description: "Slim-fit denim jeans." },
  { id: "9", name: "Scarf", description: "Warm wool scarf." },
  { id: "10", name: "Boots", description: "Waterproof hiking boots." },
];

export async function generateStaticParams() {
  return mockProducts.map((product) => ({
    id: product.id,
  }));
}

// ISR configuration: revalidate every 1 hour
export const revalidate = 3600;

export default async function ProductPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;

  const product = mockProducts.find((p) => p.id === id);

  if (!product) {
    notFound();
  }

  return (
    <main className="product-page">
      <div className="product-card">
        <h1 className="product-title">{product.name}</h1>
        <p className="product-description">{product.description}</p>
        <button className="product-button">Add to cart</button>
      </div>
    </main>
  );
}

app/product/isr/[id]/page.tsx

export const revalidate = 3600

This line enables ISR with a 1-hour (3,600 seconds) revalidation period. During this time, pages are served from cache. Once the period expires, the next user request triggers a background page regeneration.

generateStaticParams()

As in the SSG example, we pre-generate pages for our 10 core products. These pages are built at build time, served as static HTML, and updated through ISR when needed.

Removed dynamicParams = false

Unlike our SSG example where we used dynamicParams = false to limit access to statically generated routes, this constraint is now removed. This means Next.js will attempt to render any route matching the dynamic pattern (/product/isr/[id]), regardless of whether it was included in generateStaticParams().

This enables us to:

Serve product pages for new items without rebuilding the app.
Dynamically generate pages for long-tail or user-generated content on demand.
Return 404 conditionally when a product ID doesn't exist in the data source.

This flexibility makes the route perfect for hybrid/static-dynamic behavior—the essence of ISR.

4. Server Side Rendering (SSR)

So far, we've looked at Static Site Generation (SSG) — where pages are pre-built during deployment — and Incremental Static Regeneration (ISR), which adds scheduled or on-demand revalidation on top of SSG.

But what happens when your data changes constantly, depends on user authentication, or simply can't be predicted at build time?

Server-Side Rendering (SSR) is the answer.

With SSR, pages are rendered on the server at request time for each user visit. Rather than serving pre-rendered HTML from a cache, the server processes every incoming request individually, ensuring the data is always fresh.

✅ Key Advantages

🔄 Real-time data: Fresh content is fetched for each request, eliminating stale data.
👤 Personalization: Perfect for user-specific content like account pages and dashboards.
🔍 SEO optimization: Search engines receive fully rendered HTML with the latest content.
🔧 Dynamic control: Data fetching happens on demand — without rebuilds or revalidation.

⚠️ Limitations

🐢 Performance impact: Pages load more slowly than SSG/ISR since HTML must be generated for each request.
🧱 Scaling complexity: High traffic can strain server resources and increase response times.
💸 Higher costs: Increased server processing leads to greater infrastructure expenses.

🛠️ Implementation

Let's now modify our previous product details page to implement SSR, which will dynamically render the page each time an user requests it.

import { notFound } from "next/navigation";

import "./ProductPage.css";

type Product = {
  id: string;
  name: string;
  description: string;
};

const mockProducts: Product[] = [
  { id: "1", name: "T-Shirt", description: "Comfortable cotton t-shirt." },
  { id: "2", name: "Sneakers", description: "Lightweight running shoes." },
  { id: "3", name: "Watch", description: "Elegant analog wristwatch." },
  { id: "4", name: "Backpack", description: "Durable everyday backpack." },
  { id: "5", name: "Sunglasses", description: "Polarized UV protection." },
  { id: "6", name: "Hat", description: "Stylish summer hat." },
  { id: "7", name: "Jacket", description: "Windproof outdoor jacket." },
  { id: "8", name: "Jeans", description: "Slim-fit denim jeans." },
  { id: "9", name: "Scarf", description: "Warm wool scarf." },
  { id: "10", name: "Boots", description: "Waterproof hiking boots." },
];

export default async function ProductPage(props: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await props.params;

  const product = mockProducts.find((p) => p.id === id);

  if (!product) {
    notFound();
  }

  return (
    <main className="product-page">
      <div className="product-card">
        <h1 className="product-title">{product.name}</h1>
        <p className="product-description">{product.description}</p>
        <button className="product-button">Add to cart</button>
      </div>
    </main>
  );
}

app/product/ssr/[id]/page.tsx

🧠 Explanation

No generateStaticParams()

Unlike SSG and ISR, this implementation doesn’t use generateStaticParams() at all. The route is fully dynamic — there's no list of valid product IDs generated at build time.

No dynamicParams or revalidate flags

Since this page is rendered on every request, there’s no need to configure dynamicParams or revalidate. Each time the page is accessed, Next.js will evaluate the component on the server.

5. Client-Side Rendering (CSR)

We've now covered Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Server-Side Rendering (SSR)—all involving server-side logic or pre-rendering. But there's one more model to explore: Client-Side Rendering (CSR).

With CSR, the server sends a minimal HTML shell and JavaScript bundle to the browser. The browser then renders the page content entirely on the client by fetching data from an API or other source. This powers traditional Single Page Applications (SPAs) and remains a valid strategy in Next.js when used strategically.

While Client-Side Rendering is fundamental to React development, it's generally not ideal as a default rendering strategy at the page level in Next.js—particularly for content requiring strong SEO or fast initial visibility. Instead, CSR excels with specific, interactive components like filters, carousels, modals, or client-specific widgets.

✅ Key Advantages

🧠 Enhanced interactivity: Perfect for dynamic, app-like experiences where user interaction is crucial.
🧍 User-specific data: Content personalizes directly in the browser without server-side processing.
🚀 Seamless navigation: Next.js' built-in routing and client caching enable instant page transitions.

⚠️ Limitations

🐢 Slower initial load: Users must wait for JavaScript to load and data fetching to complete before seeing content.
🔍 SEO limitations: Search engines may struggle to index client-rendered content, despite improvements in modern crawlers.
🔌 JavaScript dependency: The page becomes non-functional if JavaScript is disabled or fails to load.
📦 Larger JS bundles: Additional client-side logic increases bundle size, affecting performance on slower devices and networks.

⚠️ Important Note

Even though Client Components run primarily in the browser, they are still pre-rendered on the server during the initial request. Next.js uses this approach to deliver a minimal HTML shell, which improves initial load performance and perceived speed.

After the HTML arrives, JavaScript "hydrates" the components on the client, making them fully interactive.

🧠 Be careful: When server-rendered markup doesn't match client-side JavaScript during hydration, you may encounter hydration errors. These errors can break your UI or trigger console warnings. Common causes include non-deterministic values (like Date.now(), Math.random()) or mismatched state between server and client.

🛠️ Implementation

"use client";

import { useParams } from "next/navigation";

import "../../ProductPage.css";
import { useEffect, useState } from "react";

type Product = {
  id: string;
  name: string;
  description: string;
};

const mockProducts: Product[] = [
  { id: "1", name: "T-Shirt", description: "Comfortable cotton t-shirt." },
  { id: "2", name: "Sneakers", description: "Lightweight running shoes." },
  { id: "3", name: "Watch", description: "Elegant analog wristwatch." },
  { id: "4", name: "Backpack", description: "Durable everyday backpack." },
  { id: "5", name: "Sunglasses", description: "Polarized UV protection." },
  { id: "6", name: "Hat", description: "Stylish summer hat." },
  { id: "7", name: "Jacket", description: "Windproof outdoor jacket." },
  { id: "8", name: "Jeans", description: "Slim-fit denim jeans." },
  { id: "9", name: "Scarf", description: "Warm wool scarf." },
  { id: "10", name: "Boots", description: "Waterproof hiking boots." },
];

export default function ProductPage() {
  const { id } = useParams();

  const [product, setProduct] = useState<Product>();
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchProduct() {
      await new Promise((resolve) => setTimeout(resolve, 1000)); // Simulate network delay
      const product = await new Promise<Product | undefined>((resolve) =>
        resolve(mockProducts.find((product) => product.id === id))
      );

      setProduct(product);
      setLoading(false);
    }

    fetchProduct();
  }, [id]);

  if (loading) {
    return (
      <main className="product-page">
        <p className="loading-message">Loading product...</p>
      </main>
    );
  }

  if (!product) {
    return (
      <main className="product-page">
        <p className="product-not-found">Product not found</p>
      </main>
    );
  }

  return (
    <main className="product-page">
      <div className="product-card">
        <h1 className="product-title">{product.name}</h1>
        <p className="product-description">{product.description}</p>
        <button className="product-button">Add to cart</button>
      </div>
    </main>
  );
}

app/product/csr/[id]/page.tsx

🧠 Explanation

All logic is inside useEffect()

Unlike SSG, ISR, or SSR where data fetching happens on the server, in CSR everything happens on the client, and all logic related to fetching product data is encapsulated inside a useEffect() hook. This hook triggers after the component mounts and retrieves the necessary data based on the URL parameter.

**"use client" directive**

This directive tells Next.js to treat the component as a client component, allowing hooks like useState, useEffect and useParams to function properly.

Route handling with useParams()

Instead of receiving params from the server (like in SSG/SSR), the id is pulled from the client-side router using useParams().

Custom loading state

As right now browser is not handling a loading state by itself (by loading the page content) there is a need to implement a custom one. To simulate real network latency setTimeout delay has been used. This mimics how a real client would experience remote API requests.

🧾 6. Summary: Choosing the Right Rendering Strategy in Next.js for E-commerce

Next.js offers four major powerful rendering strategies—Static Site Generation (SSG), Incremental Static Regeneration (ISR), Server-Side Rendering (SSR) and Client-Side Rendering (CSR). Each strategy has unique benefits, and choosing the right one for each route or component lets you optimize for performance, SEO, interactivity, and scalability.

Here's how they compare:

Rendering Strategy	Render Time	Best For	Pros	Cons
SSG	Build time	Static pages, rarely updated product details	🔹 Fastest performance 🔹 Great for SEO 🔹 CDN-ready	🔸 Requires rebuilds for updates 🔸 Not suitable for live data
ISR	Build + Revalidate	Product pages updated periodically or on demand	🔹 Balance of freshness & speed 🔹 Supports invalidation	🔸 Slightly stale content possible 🔸 More setup complexity
SSR	Per request	Dynamic content, personalization, stock/pricing	🔹 Always up-to-date 🔹 Supports user-specific logic	🔸 Slower first load 🔸 Requires server infrastructure
CSR	Client-only	Isolated, interactive components (e.g. cart)	🔹 Full interactivity 🔹 Useful for client-only logic	🔸 SEO limitations 🔸 Slower initial render 🔸 Larger JS bundle

🛒 E-commerce Use Case Recommendations

Landing pages, policies, info pages: → ✅ SSG
Product listings/details with moderate updates: → ✅ ISR
Product listings/details with frequent updates, personalized prices, live inventory, and A/B tests: → ✅ SSR
Client-only interactions (cart, wishlist, filters): → ✅ CSR

🔭 7. What’s Next?

The rendering strategies discussed in this article — SSG, ISR, SSR, and CSR — form the foundation of Next.js, particularly for e-commerce applications where performance and SEO are crucial.

But this is just the beginning.

In upcoming articles, we'll explore more advanced techniques from recent Next.js versions, including:

Streaming and Suspense for progressive rendering and better UX,
Partial Prerendering (PPR) to efficiently combine static and dynamic elements on the same page,
Techniques to optimize per-component rendering strategies in large-scale applications.

These approaches provide more precise control over performance and user experience—especially valuable for highly dynamic, personalized, and large-scale e-commerce platforms.

Stay tuned!

Why Next.js is one of the best solutions for E-commerce?

Paweł Sobolewski — Tue, 01 Jul 2025 08:43:05 +0000

In the constantly changing world of web development, e-commerce poses a unique set of challenges: complex product data, dynamic content, SEO demands, fast page loads, secure checkout flows, integration with multiple external systems and many, many more.

As developers, we’re constantly looking for tools that help us deliver all of this without compromising on performance or maintainability. Next.js delivers on all fronts — and then some more.

If you’re evaluating tech stacks for your next e-commerce project, here’s why Next.js deserves a spot at the top of your list.

1. Performance by Design

E-commerce websites live and die by performance. According to Google, even a one-second delay in page load time can reduce conversions by up to 20%. Next.js addresses this head-on by giving you multiple rendering strategies:

Static Site Generation (SSG)
Server-Side Rendering (SSR)
Client Side Rendering (CSR)
Incremental Static Regeneration (ISR)
Partial Prerendering (PPR, currently experimental)

This per-route rendering flexibility lets you optimize each part of your store — from blazing-fast landing pages to real-time personalized carts.

2. Built-in SEO Superpowers

Next.js delivers server-rendered HTML out of the box, making sure search engines like Google can immediately crawl meaningful content. For developers, this translates to:

Full control of metadata with next/head, metadata object or even dynamic content with generateMetadata function
SEO-friendly dynamic routing
Easily integrated structured data for rich search snippets

When search engines properly index your category and product pages, you'll see a natural boost in organic traffic.

3. Smart Data Caching and Request Management for Better Performance

In e-commerce, caching goes beyond storing page content. A major performance boost comes from efficient data fetching and preventing duplicate requests — crucial when handling large product catalogs, filtering systems, and personalized content.

Next.js provides complete control over data-layer caching, from server to edge computing. Better yet, it works out of the box without any custom configuration, thanks to its extended node fetch utility.

Request Memoization - During server-side rendering, Next.js stores responses received via the fetch API. This means that regardless of where and how many times you request the same data in React Server Components (RSC), the actual request occurs only once.
Data Cache - Need persistent data across multiple page renders, sessions, and users? Next.js provides this functionality out of the box by storing responses in deployed application memory in a controlled way.
Full Route Cache - By caching renderable pages generated through SSG, ISR, or forced caching, Next.js can deliver content to end users at blazing speeds.
Router Cache - Thanks to Next.js's ability to utilize both server and client environments, subsequent client-side navigations can be stored and reused within a single user session to display previously visible content immediately.

4. Streaming in Next.js: Faster Renders, Better UX, and SEO Gains

With the App Router and React Server Components, Next.js supports HTTP streaming, which allows the server to send HTML to the browser incrementally. Instead of waiting for the entire page to generate, content appears as soon as each part of the UI is ready.

This approach delivers significant performance and user experience benefits:

Time to First Byte (TTFB): The server begins sending content instantly, reducing initial load time.
Largest Contentful Paint (LCP): Essential elements like product titles, images, and prices appear early, with secondary components streaming in afterward.
Perceived performance: Users see content faster, creating a more responsive experience.

On the SEO side, streaming offers two key advantages:

Search engine bots can begin parsing HTML immediately through the open connection, continuously receiving the page's complete structure.
The streamed content remains server-rendered HTML rather than client-side JS, ensuring all content—including personalized and dynamic elements—stays crawlable and indexable.

This delivers the best of both worlds: rapid initial loads and complete SEO visibility, regardless of page complexity or personalization.

5. Multiple Layouts for Complex E-commerce Experiences

Modern e-commerce sites need various specialized layouts beyond basic shop pages, including:

Marketing landing pages
Product listings and product detail pages (PDPs)
Checkout and cart interfaces
User dashboards for orders and subscriptions
Admin and vendor portals
Blog and content sections

Next.js supports multiple layouts out of the box - a significant advantage for e-commerce projects with diverse page types. You can define distinct layouts for different pages while maintaining shared elements like navigation and cart state across views. This approach keeps your code organized and helps scale a complex store into a modular, app-like experience.

6. Integrating Next.js with Advanced Backends like Medusa

For developers building fully customizable commerce systems, frameworks like Medusa have gained significant popularity. Medusa offers a modular, open-source backend that provides plug-and-play services for products, carts, orders, payments, and more.

Next.js pairs exceptionally well with platforms like Medusa for several reasons:

It seamlessly integrates with Medusa's REST API,
You can leverage Next.js API routes as middleware between Medusa and the frontend (for authentication or webhook handling),
Medusa's modular services (inventory, discounts, fulfillment) align perfectly with Next.js's page-level rendering logic,
When combined with ISR and caching, you can scale dynamic product catalogs while maintaining peak performance.

Simply put, Medusa manages your backend business logic while Next.js provides complete control over the customer-facing experience — maintaining a clean separation of concerns.

Final Thoughts

Whether you're launching a new storefront or modernizing an existing one, Next.js delivers the performance, flexibility, and future-ready architecture that modern e-commerce platforms demand. It empowers teams to create lightning-fast shopping experiences, boost SEO performance, and integrate seamlessly with both legacy systems and modern headless commerce platforms.

Next.js provides a robust foundation for building exceptional digital retail experiences that serve both current needs and future growth. Its capabilities enhance user experience while supporting sustainable, long-term development.

Stay tuned for upcoming articles that will explore these topics in depth, complete with practical examples and real-world use cases.

DEV Community: Paweł Sobolewski

React Server and Client Components in Next.js: Understanding the Difference

What Are Server Components?

Key Characteristics:

Example:

What Are Client Components?

Example:

Important:

Combining Server and Client Components

Example:

Passing Server Components as Props

Hydration and Common Pitfalls

Common Causes of Hydration Errors:

How to Avoid Them:

Quick Comparison

Conclusion

Next.js Streaming Explained: Faster Rendering vs CSR & SSR

Why Use Streaming in Next.js?

Next.js Streaming vs Client-Side Rendering (CSR)

Client-Side Rendering (CSR)

Streaming

How Next.js Streaming Works with React Server Components

Using the React use Hook for Streaming in Next.js

Why this matters:

Does Next.js Streaming Require JavaScript?

Next.js Streaming Example with Code (SSR vs CSR vs Streaming)

Next.js Performance Benchmark: SSR vs CSR vs Streaming

Conclusion: Why Streaming is Best for Next.js Performance

FAQ Section

SSG, ISR, SSR, CSR: which strategy should I use in my Next.js e-commerce platform?

Introduction

1. Static Rendering vs Dynamic Rendering

⚙️ What triggers dynamic rendering?

2. Static Site Generation (SSG)

✅ Key Advantages

⚠️ Limitations

🛠️ Implementation

🧠 Explanation

3. Incremental Static Regeneration (ISR)

❓How it works

✅ Key Advantages

⚠️ Limitations

🛠️ Implementation

4. Server Side Rendering (SSR)

✅ Key Advantages

⚠️ Limitations

🛠️ Implementation

🧠 Explanation

5. Client-Side Rendering (CSR)

✅ Key Advantages

⚠️ Limitations

⚠️ Important Note

🛠️ Implementation

🧠 Explanation

🧾 6. Summary: Choosing the Right Rendering Strategy in Next.js for E-commerce

🛒 E-commerce Use Case Recommendations

🔭 7. What’s Next?

Why Next.js is one of the best solutions for E-commerce?

1. Performance by Design

2. Built-in SEO Superpowers

3. Smart Data Caching and Request Management for Better Performance

4. Streaming in Next.js: Faster Renders, Better UX, and SEO Gains

5. Multiple Layouts for Complex E-commerce Experiences

6. Integrating Next.js with Advanced Backends like Medusa

Final Thoughts

Using the React `use` Hook for Streaming in Next.js