DEV Community: Paweł Sobolewski

Building a Multilingual Shop with Next.js

Paweł Sobolewski — Tue, 01 Sep 2026 22:00:00 +0000

Adding multiple languages to a web application often starts with a simple step: replacing hardcoded strings with translation keys and adding a language switcher.

In an e-commerce application, however, internationalization quickly becomes a broader architectural challenge.

Language affects far more than the text displayed on the page:

It becomes part of the URL,
it influences routing and redirects,
it determines which translation resources are loaded,
it affects server and client rendering,
it changes how data such as prices and dates should be formatted.

In this article, we’ll look at how to approach these problems in a Next.js application using the App Router. Rather than focusing on the basics of translating strings, we’ll focus on the technical decisions behind the implementation: how the language is detected, how it’s propagated through the application, how translations are loaded on the server and client, and how localized routes are handled.

The implementation presented here is based on a small e-commerce shop, with a product page as its main piece of domain content. It supports English, Polish, and German, and it intentionally stays focused on the internationalization layer rather than on building a complete commerce platform.

The goal is to use this relatively simple application to explore the architecture behind multilingual Next.js applications and the trade-offs involved in choosing and implementing an i18n solution.

Implementation Remarks

Before diving into the implementation, it’s worth noting a few deliberate simplifications in this project.

The repository is intentionally designed to demonstrate the technical aspects of internationalization in Next.js, not to provide a complete, production-ready e-commerce application. As a result, some parts of the implementation are intentionally simplified.

Repository link

Product data is part of the translation resources

To keep the example self-contained, product data such as names and descriptions is stored alongside the translation resources.

In a real e-commerce application, this data would typically come from a domain-specific API or commerce backend:

Product page
    ↓
Commerce API
    ↓
Product data

In that setup, the i18n layer would primarily handle UI translations, while localized product content would be part of the product data model.

All languages are stored in a single file

The example keeps translations for all supported languages in one file to make the structure easier to explore.

In a larger application, each language would typically have its own resource files:

languages/
├── en/
│   ├── common.json
│   ├── home.json
│   └── product.json
├── pl/
│   ├── common.json
│   ├── home.json
│   └── product.json
└── de/
    ├── common.json
    ├── home.json
    └── product.json

This makes translation files easier to manage independently and fits better with external localization workflows.

No external translation management system

The project uses local resources and an API route to demonstrate the resource-loading boundary.

In a production application, you might instead use a CMS, a translation management platform, or another external service. The resourceLoader abstraction is intentionally designed so the underlying source can be swapped out without changing the components that consume translations.

Choosing an i18n Solution for Next.js

Before implementing internationalization, the first step is choosing the right tool.

Next.js provides the routing primitives needed to build a multilingual application, but it doesn’t prescribe a translation library. That leaves several options: building a small custom solution, using a Next.js-focused library such as next-intl, or adopting the broader i18next ecosystem through next-i18next.

For this project, I chose next-i18next.

That decision wasn’t based solely on the number of translated strings. The application needs an i18n layer that works across Server and Client Components, supports namespaces, and gives us control over how translation resources are loaded. These are important capabilities for a shop where translations may eventually move from local files to an external CMS or another backend service.

next-i18next is built on top of i18next and react-i18next, while adding the Next.js-specific integration. The version used in this project supports the App Router, including Server Components, Client Components, and proxy-based language detection*.* It also provides separate APIs such as getT() for Server Components and useT() for Client Components.

Why not build it ourselves?

A custom implementation might initially look attractive. With a small application, a simple dictionary and a React context can be enough:

const translations = { en: { ... }, pl: { ... }, de: { ... }, };

The problem is that translation lookup is only one part of the equation.

Once the application needs server-side translations, client-side hydration, namespaces, fallback languages, language detection, or external translation resources, the custom solution starts accumulating infrastructure that an established i18n library already provides.

There’s another important advantage: a mature i18n library gives us much more than a simple key → string lookup.

For example, i18next provides built-in support for interpolation:

t("welcome", { name: "John" });

It also supports pluralization without requiring us to implement language-specific rules ourselves, and react-i18next provides the <Trans> component for translations that contain React elements or more complex markup.

These features may seem like minor conveniences at first, but they quickly become important as the number and complexity of translations grow. Pluralization is particularly difficult to implement correctly because different languages can have completely different grammatical rules.

Language-Based Routing

Once we have chosen the i18n library, the next decision is where the current language should live.

For this application, the language is part of the URL:

/en
/pl
/de

The same applies to nested routes:

/en/product/1
/pl/product/1
/de/product/1

This is implemented using a dynamic segment in the App Router:

app/
└── [lng]/
    ├── page.tsx
    └── product/
        └── [id]/
            └── page.tsx

The [lng] segment becomes a route parameter, so a product page receives both the language and the product identifier:

const { id, lng } = await params;

A small App Router detail: Starting with Next.js 16.3.0, you can also access route parameters via next/root-params. For example, instead of passing lng through multiple component levels, a component can use:
import { lng } from "next/root-params";
This can reduce prop drilling when deeper components need the language. It’s especially useful for components that rely on route parameters but don’t otherwise need props from their parent.

Why put the language in the URL?

The first benefit is that each language has its own URL.

A user can navigate directly to:

/pl/product/1

and the server immediately knows which language to use to render the page.

The URL is also shareable and bookmarkable. If someone sends a Polish product page to another user, they’re sharing the Polish version explicitly rather than relying on the recipient’s browser preferences.

There is also a clear relationship between URLs:

/en/product/1
/pl/product/1
/de/product/1

They represent the same resource in different languages.

This is especially useful for SEO, where language-specific URLs can be indexed and connected using mechanisms such as hreflang.

Detecting the User's Language with Proxy

Putting the language in the URL solves the routing problem, but it raises another question: what should happen when a user visits the application without specifying a language?

For example:

GET /

There is no language in the URL, so the application needs a way to determine the most appropriate one.

In this project, that logic lives in the Next.js Proxy and follows a simple priority order:

URL
 ↓
Cookie
 ↓
Accept-Language
 ↓
Fallback

The key point is that these sources are not treated equally.

URL comes first

If the requested URL already contains a supported language, we treat it as an explicit user choice.

For example:

/pl/product/1

should always be rendered in Polish, even if the user's browser prefers German.

The Proxy first extracts the first segment of the pathname and checks whether it is one of the supported languages:

const { pathname } = request.nextUrl;

const urlLanguage = pathname.split("/")[1];

if (supportedLanguages.includes(urlLanguage)) {
  // ...
}

When a valid language is found, the request can continue normally.

The Proxy also updates the language cookie to remember the user's explicit choice for subsequent visits.

Cookie as persistent preference

If there is no language in the URL, the next source is the language cookie.

The cookie allows us to remember a language selected during a previous visit without requiring the user to select it again.

However, the cookie is deliberately lower in the priority chain than the URL.

This means that:

URL:    /de
Cookie: pl

results in German.

The URL represents the current request, while the cookie represents a previously stored preference.

Keeping this distinction prevents a stale cookie from overriding an explicit URL.

Falling back to `Accept-Language`

If neither the URL nor the cookie provides a supported language, we can use the browser's Accept-Language header.

A browser might send something like:

pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7

The application extracts the language codes and looks for the first one it supports.

For this project, the supported languages are:

en
pl
de

so the example header would result in:

pl

It is important to treat Accept-Language as a preference, rather than as a guaranteed language selection. The browser may request a language that the application does not support.

Finally, use a fallback

There is always a case where none of the detected languages are supported.

For example:

URL:    /
Cookie: fr
Header: ja-JP,ja;q=0.9

If the application only supports English, Polish and German, there is no match.

This is where the configured fallback language is used:

en

Translation Resources and Namespaces

Once the language is established, the next question is how the application retrieves the translations.

The project uses three namespaces:

common
home
product

Rather than keeping every translation in a single large dictionary, namespaces let us group resources by responsibility.

For example:

common
├── navigation
├── language switcher
└── shared UI

home
├── hero
└── product grid

product
├── product details
├── add to cart
└── stock information

This becomes increasingly useful as the application grows. A single translation file works well at first, but over time it becomes harder to maintain and to understand which part of the application owns a particular key.

Namespaces also provide a useful loading boundary. A product page doesn’t necessarily need every translation used by the homepage.

Loading resources through `resourceLoader`

The interesting part of this implementation is how those resources are loaded.

Instead of importing the translation JSON directly into the application, next-i18next is configured with a custom resourceLoader:

resourceLoader: async (language, namespace) => {
  const baseUrl =
    process.env.NEXT_PUBLIC_BASE_URL ?? "http://localhost:3000";

  const res = await fetch(
    `${baseUrl}/api/fetchTranslations?lang=${language}&ns=${namespace}`,
  );

  if (!res.ok) {
    throw new Error(
      `Failed to load translations: ${language}/${namespace}`,
    );
  }

  return res.json();
},

Why introduce an API layer?

For local JSON files, calling an API might seem unnecessary—we could simply import them.

The API is included here to illustrate a more realistic setup, where translations are managed outside the application bundle.

Imagine replacing the current implementation with:

resourceLoader
     ↓
    CMS

or:

resourceLoader
     ↓
translation service

The rest of the application can remain unchanged.

This separation is especially useful for e-commerce applications, where translations are often managed by content or localization teams rather than developers.

Server and Client Components

With the language and translation resources in place, we still need to answer one key question: how do Server Components and Client Components access translations?

The App Router provides two execution environments, and next-i18next offers an API for each.

On the server, translations can be accessed with getT():

const { t } = await getT("product");

const title = t("title");

On the client, translations are accessed through useT():

const { t } = useT("common");

return <button>{t("addToCart")}</button>;

This distinction matters because using translations doesn’t automatically mean a component needs to become a Client Component.

Keep translated content on the server

A product page is a good example.

There’s usually no reason to move the entire page to the client just because it contains translated text. The product name, description, labels, and other static content can be translated as the page is rendered on the server.

That way, the application can send translated HTML in the initial response instead of waiting for client-side JavaScript to initialize the translation layer.

Providing the resources from the layout

The [lng]/layout.tsx file is where the server-loaded translation resources are passed into the client-side i18n context.

The layout initializes the server-side i18n instance and obtains the loaded resources:

const { i18n } = await getT();
const resources = getResources(i18n);

Those resources are then passed to the provider:

<I18nProvider
  language={language}
  resources={resources}
>
  {children}
</I18nProvider>

The layout therefore establishes the translation context once for the entire language-specific part of the application.

Why this separation matters

With the App Router, we should generally default to Server Components.

The reason is simple: turning a component into a Client Component moves its logic into the browser and can add JavaScript that isn’t otherwise necessary.

Internationalization shouldn’t be the reason to do that.

If a component only needs to render translated content, it can remain a Server Component and use getT().

useT() should be reserved for components that already need to run on the client — for example, because they handle user interaction, browser events, local state, or other client-side behavior.

Formatting Prices

Internationalization is not limited to translating text. Numbers, dates, currencies, and other values often need to be formatted according to the user's language as well.

Prices are a simple example.

The same value:

1999.99

can be displayed differently depending on the language:

$1,999
1 999 zł
1.999 €

In this project, the language used in the URL is a short code such as en, pl, or de. However, the Intl APIs work with more specific locale identifiers, such as en-US or pl-PL.

The formatPrice utility handles this mapping:

const LOCALE_CURRENCY: Record<string, string> = {
  en: "USD",
  pl: "PLN",
  de: "EUR",
};

const LOCALE_BCP47: Record<string, string> = {
  en: "en-US",
  pl: "pl-PL",
  de: "de-DE",
};

There are two separate mappings here.

LOCALE_CURRENCY determines which currency should be displayed, while LOCALE_BCP47 determines the regional formatting conventions used by Intl.NumberFormat.

The actual formatting is then kept in a small utility:

export function formatPrice(price: number, language: string): string {
  const currency = LOCALE_CURRENCY[language] ?? "USD";
  const bcp47 = LOCALE_BCP47[language] ?? "en-US";

  return new Intl.NumberFormat(bcp47, {
    style: "currency",
    currency,
    maximumFractionDigits: 0,
  }).format(price);
}

This gives components a simple API:

formatPrice(product.price, lng);

without requiring them to know anything about currencies, BCP 47 locale identifiers, or Intl.NumberFormat.

Localized Navigation

As language becomes part of the URL, navigation is one of the first areas where i18n can start leaking into your application code.

Without an abstraction, every link needs to be aware of the current language:

<Link href={`/${lng}/product/${id}`}>
  Product
</Link>

This works, but it couples the component directly to the routing structure.

It also gets repetitive: every developer has to remember that the first URL segment represents the current language.

To avoid this, the project introduces a LocalizedLink component.

LocalizedLink

The idea is simple: components provide a path relative to the language root, and LocalizedLink adds the current language automatically.

Instead of:

<Link href={`/${lng}/product/${id}`}>
  Product
</Link>

we can write:

<LocalizedLink href={`/product/${id}`}>
  Product
</LocalizedLink>

If the current language is Polish, the resulting URL is:

/pl/product/1

For German, it becomes:

/de/product/1

This way, the component hides a routing detail that’s irrelevant to the component using it.

Switching between languages

The language switcher is a slightly different case.

Here, we want to change the language while preserving the current route.

For example, if the user is currently on:

/pl/product/1

switching to German should result in:

/de/product/1

rather than simply navigating to /de.

The switcher can therefore treat the current pathname as a resource-independent path and replace only the language segment.

Conceptually:

Current URL
/pl/product/1
      │
      │ replace language
      ▼
/de/product/1

This is important for product pages because changing the language should not interrupt the user's current context.

Production Considerations

The implementation covers the core architecture, but a production application would still need to address a few additional concerns.

Caching translation resources

Translation resources are usually much more stable than application data. Fetching the same translations on every request would therefore be wasteful.

The resourceLoader is a natural place to introduce caching and revalidation:

Component
    ↓
next-i18next
    ↓
resourceLoader
    ↓
cache
    ↓
translation source

The exact strategy depends on where the translations are stored. With a CMS or external translation service, the application could use Next.js caching and revalidation to avoid unnecessary requests while still allowing updated translations to reach users without rebuilding the entire application.

SEO and `hreflang`

Language-specific URLs also make SEO an important consideration.

For example:

/en/product/1
/pl/product/1
/de/product/1

These URLs represent different language versions of the same page. A production application should expose this relationship to search engines using appropriate hreflang metadata.

Canonical URLs should also be generated consistently so that each language version points to itself as the canonical URL, while the hreflang links connect the available alternatives.

The routing architecture already provides a clear URL for each language version. SEO metadata can build on top of that structure instead of inferring the language from cookies or client-side state.

Conclusion

Building a multilingual application with Next.js isn’t just about translating strings. Language affects routing, request handling, resource loading, rendering, and navigation, so internationalization quickly becomes an architectural concern.

The implementation presented here addresses those concerns at well-defined boundaries. The language is part of the URL, Proxy handles language detection, next-i18next provides the translation layer, and Server and Client Components use different APIs depending on where translations are needed. Application-specific abstractions such as LocalizedLink then keep language-related details out of regular components.

Next.js Server Actions vs API Routes: Architecture, Performance, and Use Cases

Paweł Sobolewski — Tue, 05 May 2026 22:00:00 +0000

With the introduction of the App Router, Next.js added two powerful server-side primitives:

At first glance, they might seem interchangeable—both run on the server. But they're designed for different responsibilities, follow different execution models, and come with different constraints.

Understanding these differences is essential to avoid architectural pitfalls and performance issues.

What Are Server Actions?

According to the official documentation, Server Actions are a specific type of React Server Function used for mutations. They are invoked from the client by sending a POST request to the current page’s route (the same URL context in which the action was triggered), where Next.js internally routes the request to the corresponding server-side function based on unique server action identifier.

Here's an important clarification:

We only call them Server Actions when they're invoked from the client.

From the server's perspective, they're just regular asynchronous functions.

For example:

"use server"

export async function updateUser() {
    // mutation logic
}

Called from a Client Component → acts as a Server Action
Called from another server-side function (like server component) → just a normal function call

This distinction is crucial:

The network boundary only exists when invoked from the client,
The serialization and execution constraints only apply in that context.

Key characteristics

Must be asynchronous
Marked with the "use server" directive
Invoked via POST requests under the hood

Mutations + Rendering = Sequential Constraints

The official documentation states that React Server Functions are designed for server-side mutations. This design choice is directly tied to one of their most important limitations.

When a Server Action is invoked:

It mutates server-side state
It triggers a React Server Component (RSC) re-render
It produces a new UI snapshot
The client merges the updated result

This tight coupling between mutation and rendering means React must ensure each update applies to a consistent version of the UI tree.

This creates a critical constraint described in the docs:

The client currently dispatches and awaits them one at a time

What this means in practice

Even if multiple Server Actions are triggered “at once”:

useEffect(() => {
    actionA();
    actionB();
}, [])

They will execute sequentially, not in parallel:

actionA → re-render → actionB → re-render

This is not an implementation detail—it is a consequence of the architecture.

Running them in parallel would risk:

race conditions between mutations
inconsistent UI snapshots
stale data being rendered

So React prioritizes consistency over concurrency.

Future note

The documentation explicitly indicates that this behavior is current, which means it may change in the future. However, today:

You should design your system assuming Server Actions are sequential

What Are Route Handlers?

Route Handlers address a key limitation of Server Actions: the lack of true concurrent, independent calls.

Because Server Actions are tightly coupled with React's rendering lifecycle, they aren't suited for scenarios where multiple operations must run in parallel without UI-driven synchronization.

Route Handlers provide a decoupled HTTP-based execution model that restores full concurrency and independence between requests.

Definition

Route Handlers are standard HTTP endpoints defined in:

app/api/.../route.ts

Example:

import { NextResponse }from"next/server"

export async function POST(request: Request) {
    const body= await request.json();

    await db.cart.add(body.productId);

    return NextResponse.json({ success:true });
}

Key characteristics

Full HTTP interface
Support for all HTTP methods (GET, POST, etc.)
Publicly accessible endpoints
Independent of React rendering lifecycle
Fully parallelizable and concurrent by default

Good to know

In older versions of Next.js there were only Route Handlers, as Server Action concept came with React Server Components in Next.js 13. So they are improving specific use cases, not replacing them. You can still write the whole application using only Route Handlers and not writing a single Server Action at all.

Why Use Server Actions?

At this point, you might ask:

If Route Handlers provide full concurrency, HTTP control, and fewer constraints—why use Server Actions at all?

Server Actions aren't meant to replace Route Handlers. They solve a different class of problems: UI-driven mutations tightly integrated with React's rendering model, not transport-layer API design.

1. They eliminate the client–server API layer

With Route Handlers, every mutation typically requires:

defining an API endpoint
handling request/response manually
writing client-side fetch calls
managing loading and error states explicitly

Server Actions remove this entire layer:

<form action={createPost}>
    <input name="title"/>
    <button type="submit">Create</button>
</form>

No more:

manual fetch calls
endpoint definitions
request parsing boilerplate

The mutation becomes a direct extension of the UI.

2. They're first-class citizens of React Server Components

Server Actions are deeply integrated with the RSC model:

They trigger server component re-renders
They return updated UI state without manual client synchronization
They work seamlessly with Next.js caching and revalidation primitives

This creates a unique property:

A mutation can immediately reflect in the UI—without explicitly managing state on the client.

Route Handlers can't do this. They only return data.

3. They reduce client-side complexity

With Route Handlers, a typical mutation flow looks like:

await fetch("/api/posts", { method:"POST", body: ... });
setState(...);
handleLoading(...);
handleError(...);

With Server Actions:

no manual request lifecycle
no fetch boilerplate
no explicit client-state synchronization layer

This shifts complexity from the client to the framework boundary.

Conclusion

Server Actions are powerful but intentionally constrained.

They are:

React-integrated mutation primitives designed for UI-driven updates—not general-purpose concurrency.

Choosing between Server Actions and Route Handlers isn't about preference—it's about understanding whether your problem belongs to the UI layer or the transport/API layer.

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

Building a Multilingual Shop with Next.js

Implementation Remarks

Product data is part of the translation resources

All languages are stored in a single file

No external translation management system

Choosing an i18n Solution for Next.js

Why not build it ourselves?

Language-Based Routing

Why put the language in the URL?

Detecting the User's Language with Proxy

URL comes first

Cookie as persistent preference

Falling back to Accept-Language

Finally, use a fallback

Translation Resources and Namespaces

Loading resources through resourceLoader

Why introduce an API layer?

Server and Client Components

Keep translated content on the server

Providing the resources from the layout

Why this separation matters

Formatting Prices

Localized Navigation

LocalizedLink

Switching between languages

Production Considerations

Caching translation resources

SEO and hreflang

Conclusion

Next.js Server Actions vs API Routes: Architecture, Performance, and Use Cases

What Are Server Actions?

Key characteristics

Mutations + Rendering = Sequential Constraints

What this means in practice

Future note

What Are Route Handlers?

Definition

Key characteristics

Good to know

Why Use Server Actions?

1. They eliminate the client–server API layer

2. They're first-class citizens of React Server Components

3. They reduce client-side complexity

Conclusion

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

Falling back to `Accept-Language`

Loading resources through `resourceLoader`

SEO and `hreflang`

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