SSR vs SSG vs ISR vs CSR in Next.js: How to Choose the Right Rendering Strategy

Rendering is simply the process of turning your React code and data into the HTML a browser displays. SSR, SSG, ISR and CSR are four different answers to one question: when and where is that HTML created?

The easiest way to remember them is a restaurant analogy:

SSG (Static Site Generation) is a packed lunch prepared in the morning. It's handed out instantly, but everyone receives the same box, and nothing changes until tomorrow's batch.

ISR (Incremental Static Regeneration) is the same lunch box, except the kitchen prepares a fresh batch every hour. Still fast, and never too old.

SSR (Server-Side Rendering) is a dish cooked to order. It's always fresh and made just for you, but you wait a little longer and the kitchen works harder.

CSR (Client-Side Rendering) is a DIY meal kit delivered to your table. You get the plate quickly, then assemble the meal yourself, which means the browser does the work.

By the end of this guide, you'll be able to look at any page in your project and decide which Next.js rendering strategy fits, and explain why.

Key Terms to Know Before You Start

Skim this table once. Every section below uses these words.

SSR vs SSG vs ISR vs CSR: A Side-by-Side Comparison

Worth remembering: SSG and ISR are really the same idea. ISR is just SSG with an expiry date.

1. Static Site Generation (SSG): Build Once, Serve Everyone

In one line: Next.js creates the HTML when you run next build, and every visitor receives that same file.

Use it when the page is identical for everyone and only changes when you deploy. Think About, Contact, Privacy Policy and documentation pages.

The good news is that in the Next.js App Router, this is the default. If your page doesn't read anything about the visitor, it's already static, and you don't need to write any special code:

For pages with a URL parameter, such as /docs/[slug], tell Next.js which pages to build ahead of time using generateStaticParams:

Watch out for:

Reading cookies or headers turns static rendering off. If you call cookies() or headers() anywhere in the page or its layout, Next.js quietly switches the page to SSR.

Dates freeze at build time. If you show new Date() on a static page, it will display the build time forever.

2. Incremental Static Regeneration (ISR): Static, Refreshed on a Timer

In one line: the page is static like SSG, but Next.js quietly rebuilds it in the background after a time you choose.

Use it when the page is the same for everyone but the content changes now and then. Good examples are CMS-driven blog posts, product pages and news lists.

Add a single line, revalidate, with the number of seconds:

How the refresh works, step by step:

A visitor arrives after the hour is up.

They still get the old page instantly.

Next.js rebuilds the page in the background.

The next visitor gets the new page.

Want the page to update the moment an editor hits Publish? Call revalidatePath('/blog') from a Server Action or an API route. This is known as on-demand revalidation.

Watch out for:

One visitor sees old content. The first person after the timer expires gets the previous version. That's expected behavior, not a bug.

Test ISR in production mode. In next dev, pages are rebuilt every time, so ISR looks broken. Run next build followed by next start to see the real behavior.

3. Server-Side Rendering (SSR): Build the Page for Every Visitor

In one line: each time someone opens the page, the server fetches the data, builds the HTML and sends it.

Use it when the page differs for each user or must always be up to date, and you still want the content in the first HTML for SEO or a fast first view. Examples include "My account", search results and order summaries.

You don't switch SSR on directly. Next.js uses it automatically when your page reads something about the request, such as cookies:

If a page doesn't read request data but you still want it built fresh every time, add this line:

Show something while users wait. Add a loading.tsx file next to your page. Next.js displays it instantly while the real page is being built:

4. Client-Side Rendering (CSR): Let the Browser Fetch the Data

In one line: the page loads first, then JavaScript in the browser fetches the data and fills it in.

Use it when the data changes while the user is looking at it, or only matters after they start interacting. Think live stock prices, chat messages, notifications and dashboard filters.

Mark the component with 'use client' and fetch in the browser. A library such as SWR or TanStack Query handles loading states, caching and refreshing for you:

A common mix-up: 'use client' alone does not mean CSR. Next.js still renders Client Components to HTML on the server first. It only becomes true client-side rendering when the data is fetched in the browser.

Watch out for:

Search engines and link previews may see an empty page. If your main content loads in the browser, Google, WhatsApp and Slack previews may miss it. Keep important content on the server.

Users see spinners. Loading the core content on the client feels slow. Use CSR for extras, not for the heart of the page.

How to Choose a Next.js Rendering Strategy: 3 Simple Questions

Answer these in order. Each answer either gives you a strategy or sends you to the next question.

Question 1: Is the page the same for every visitor?

Yes → go to Question 2 (for example, a blog post or About page).

No → go to Question 3 (for example, "My orders" or a cart).

Question 2: How old can the data be?

Fine until the next deploy → SSG. Built once and fastest (Privacy Policy, docs).

A few minutes or hours → ISR. Refreshed in the background (blog list, product page).

Must be live → go to Question 3 (live score, remaining stock).

Question 3: Does the content need to be in the first HTML? (For Google, link previews, or the main content.)

Yes → SSR. Built fresh for each visitor ("My orders", search results).

No → CSR. The browser fetches it after load (live prices, chat, notifications).

Real-World Examples

5 Common Next.js Rendering Mistakes to Avoid

Making everything SSR "to be safe." It's slower and costs more. Start static, and go dynamic only when a page truly needs request data.

Reading cookies in the root layout. This quietly turns every page in your app into SSR. Read cookies only in the page or component that needs them.

Fetching main content in useEffect. Users see a spinner and search engines may see nothing. Fetch on the server instead.

Testing ISR in dev mode. next dev rebuilds everything every time. Use next build and next start.

Setting revalidate = 1 everywhere. If data really must be that fresh, use SSR. If not, pick a longer window such as 60 or 3600 seconds.

How to Check What Your Page Actually Does

Run next build. In the output, each route has a symbol next to it:

The one rule to remember: start static, and move to SSR or CSR only when the data is personal or must be live.

Need Help Building a Fast, SEO-Friendly Next.js App?

Choosing the right rendering strategy affects page speed, search rankings and hosting costs. At [Your Company Name], our developers build high-performance Next.js and React applications, from ready-made products to fully customized solutions designed around your business.

Talk to our team about your project, or see how we can customize our products for you.