How Next.js Decides When (and How) to Render Your Pages | Serenity

A friendly guide to understanding how Next.js turns your React code into fast, user-ready web pages.

Introduction

Let's talk about building web pages. When you make a React app, your goal is to get pixels on the screen as quickly as possible. But here is the catch: picking the wrong way to build your pages can quietly slow down your app.

Imagine showing an old, saved page for a live stock ticker — your users would be looking at outdated numbers. On the flip side, imagine making your server rebuild a simple blog post from scratch every single time someone clicks on it. You would just be wasting server power and making your users wait for no reason.

Next.js is a fantastic tool that builds on top of React, letting you control exactly how and where your pages are put together. In this post, we are going deep into the Next.js engine to see how it works. We will break down the big picture, look at how different page-building methods work behind the scenes, and see how newer Next.js updates change the way we get data.

The four rendering strategies — SSG, SSR, ISR, and CSR — mapped against where and when they do their work Click to expand

Section 1: The Rendering Landscape — A Mental Model

At its core, "rendering" just means turning your React code into standard HTML that a web browser can understand and display. In an older, standard React app, this translation happens entirely inside the user's browser. But Next.js lets you move this work to a server, or even do it while you are building your app before anyone even visits the site.

To make sense of how Next.js juggles these options, let's think about it like a restaurant:

SSG is a meal prepped in advance — the kitchen makes the food before the restaurant opens, so you get your food instantly.
SSR is a meal cooked to order — the chef doesn't start until your ticket arrives. A little slower, but exactly fresh.
ISR is a pot of soup refreshed every 10 minutes — always ready, always reasonably fresh.
CSR is a hot pot restaurant — the kitchen brings raw ingredients and your browser does the cooking at the table.

SSG is pre-cooked and waiting, SSR is made to order, ISR is a soup refreshed every ten minutes, CSR is cook-at-the-table Click to expand

Section 2: Static Site Generation (SSG)

Static Site Generation (SSG) is the absolute champion of website speed. With SSG, Next.js builds the HTML for your pages ahead of time, during the build process. When you get your app ready to launch, Next.js grabs all the needed data and bakes it directly into the HTML files.

Once these files are made, they get pushed to fast servers all around the world. When a user clicks a link, the closest server just hands them the finished file instantly — no waiting for a database or server to think.

Pages Router: use getStaticProps to fetch data at build time
App Router: data fetching is cached by default

✅ Best for: Marketing pages, documentation, blog posts — anything that looks the same for every visitor and doesn't change often.

❌ Avoid for: Private user dashboards or live data feeds where things change every second.

Static Site Generation — HTML baked at build time, pushed to CDN servers globally, served instantly with no runtime cost Click to expand

Section 3: Server-Side Rendering (SSR)

Sometimes you really need the freshest data possible, or you need to know exactly who the user is before showing them a page. This is where Server-Side Rendering (SSR) steps in. With SSR, the HTML is created on the spot, every single time someone asks for the page.

A user clicks a link → your Next.js server wakes up → fetches the latest data → builds the HTML → sends it to the browser.

Pages Router: use getServerSideProps
App Router: opt out of caching so components always fetch fresh data

✅ Best for: Private dashboards, live shopping carts, dynamic social feeds, and SEO-critical pages with constantly changing data.

❌ Avoid for: Pages that look the same for every visitor — rebuilding a static page on every request wastes energy and slows things down.

Server-Side Rendering — a user clicks, the server wakes up, fetches fresh data, builds HTML, and ships it back every time Click to expand

Section 4: Incremental Static Regeneration (ISR)

If SSG is a pre-packaged meal and SSR is cooking to order, Incremental Static Regeneration (ISR) is a clever mix of both. It lets you update your fast, pre-built pages after your site is already live — without rebuilding the entire website.

Here is how it works:

A user visits the page — they instantly get the saved, static version.
In the background, Next.js checks if the page is older than your set timer (e.g. 60 seconds).
If it is stale, Next.js quietly builds a fresh version behind the scenes.
The next visitor gets the brand new page.

You can also trigger an immediate update (called on-demand revalidation) when you publish a new article or fix a typo — no waiting for a timer.

Common misconception: ISR does not make the user wait. It always serves the saved page instantly and does the hard work in the background.

✅ Best for: Product catalogues, news blogs, e-commerce pages — content that changes often but not every second.

Incremental Static Regeneration — the user always gets the saved page instantly; Next.js quietly rebuilds a fresh one in the background Click to expand

Section 5: Client-Side Rendering (CSR) — When Next.js Steps Back

Because Next.js is a full-stack framework, we talk a lot about the server. But sometimes, Next.js needs to step aside and let the user's browser do what it does best — and that is Client-Side Rendering (CSR).

In the newer App Router, everything runs on the server by default. But if you need an interactive image carousel, a button that reacts to clicks, or access to browser tools, you add the "use client" label at the top of your file. This tells Next.js to send the code to the user's browser and let it handle things.

✅ Best for: Highly interactive UI pieces, personalised menus, data that search engines do not need to read.

❌ Watch out for:

Search engines may see a blank page if your text loads too slowly
Users on slow devices may see lots of spinning loading wheels
Heavy JavaScript files can take a long time to download

Use CSR only for the interactive bits that truly need it — not the whole page.

Client-Side Rendering — the server sends a shell, the browser downloads JavaScript and renders the UI itself in the user's tab Click to expand

Section 6: Decision Framework — Choosing the Right Strategy

The beautiful thing about the modern App Router is that you do not have to pick just one strategy for a whole page. You can mix and match — the server fetches important data while the browser handles interactive buttons on the very same page.

Use this quick guide to pick the right approach:

Question	Best Strategy
Does the page look different per user?	SSR or CSR
Does content change often but look the same for everyone?	ISR
Does content almost never change?	SSG
Do search engines need to read the page?	SSR or SSG (not CSR)

Decision framework — does it differ per user, change often, or need SEO? The answer maps directly to SSR, ISR, SSG, or CSR Click to expand

Section 7: Real-World Examples

Let's see how these strategies play out in a real everyday app.

1. 🏠 Marketing Landing Page → SSG

Your company homepage needs to load in a blink to impress visitors and rank high on Google. Since it rarely changes, this is a perfect match for SSG — build once, serve everywhere, instantly.

2. 📰 News Blog → ISR

Writers publish dozens of articles a day. Rebuilding the whole site for every new post would be painfully slow. ISR lets you instantly update just the new article page while keeping the rest of the site running at full speed.

3. 📊 User Dashboard → SSR + CSR

The data is private, changes constantly, and search engines should never see it. Use SSR to check the user's login and load the main layout, then let CSR handle the interactive charts and live data feeds.

Real-world strategy map — landing page gets SSG, news blog uses ISR, private dashboard combines SSR and CSR on the same page Click to expand

Conclusion

Building a fast web app means understanding that no single approach works for everything. If you treat every page like a static document, your app will feel boring and broken. If you treat every page like a live server request, your site will be slow and expensive to run.

The magic of Next.js — especially with the modern App Router — is that it hands you the entire toolbox. By knowing exactly when to use SSG, SSR, ISR, and CSR, you can stop fighting the code and start building pages that deliver the right experience, at the perfect speed, for every single user.

alt text Click to expand