Why rendering strategy matters in NextJS - Why It Works This Way

Overview - Why rendering strategy matters

What is it?

Rendering strategy in Next.js is about deciding when and how your web pages are created and shown to users. It controls whether pages are built before a user visits, built on the fly, or updated after loading. This choice affects how fast your site feels and how well it works on different devices and networks.

Why it matters

Without a good rendering strategy, websites can feel slow, confusing, or broken. Users might wait too long to see content or get outdated information. Good rendering makes sites fast, smooth, and reliable, improving user happiness and business success.

Where it fits

Before learning rendering strategies, you should understand basic React components and how web pages load. After this, you can explore advanced Next.js features like server actions and API routes to build full applications.

Mental Model

Core Idea

Rendering strategy decides when and where your web pages are built to balance speed, freshness, and user experience.

Think of it like...

It's like deciding when to cook a meal: prepare everything in advance (pre-render), cook on order (render on request), or keep some dishes ready and finish them when ordered (hybrid). Each way affects how fast and fresh the food is served.

┌───────────────────────────────┐
│        Rendering Strategy      │
├───────────────┬───────────────┤
│ Pre-rendering │ On-demand     │
│ (Build Time)  │ Rendering     │
├───────────────┼───────────────┤
│ Static Pages  │ Server-side   │
│ (SSG)         │ Rendering (SSR)│
├───────────────┴───────────────┤
│       Client-side Rendering    │
│ (After Page Load)              │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is Rendering in Next.js

Concept: Rendering means creating the HTML that users see from your React components.

In Next.js, rendering is how your React code turns into a web page. This can happen before the user visits (pre-rendering) or after (client-side rendering). Understanding this helps you know when your page is ready to show.

Result

You understand that rendering is the process of turning code into visible web pages.

Knowing what rendering means is the base for understanding why different strategies affect speed and user experience.

2

Foundation

Types of Rendering Strategies

Concept: Next.js supports three main rendering strategies: Static Generation, Server-side Rendering, and Client-side Rendering.

Static Generation builds pages at build time, so they load fast but may be outdated. Server-side Rendering builds pages on each request, so they are fresh but slower. Client-side Rendering builds pages in the browser after loading, useful for dynamic content.

Result

You can name and distinguish the three main rendering strategies in Next.js.

Understanding these types helps you choose the right approach for your app's needs.

3

Intermediate

How Static Generation Works

Concept: Static Generation creates HTML files during build time that are served instantly to users.

When you use Static Generation, Next.js runs your page code once when you build your app. It saves the HTML and serves it to every user. This makes pages load very fast because the server just sends a ready file.

Result

Pages load quickly because they are pre-built and served as static files.

Knowing that static pages are built once explains why they are fast but need rebuilding to update content.

4

Intermediate

How Server-side Rendering Works

Concept: Server-side Rendering builds the page HTML on each user request, ensuring fresh content.

With Server-side Rendering, Next.js runs your page code every time someone visits. It creates the HTML on the server and sends it immediately. This means users get the latest data but may wait longer for the page to load.

Result

Users see up-to-date content but may experience slower initial load times.

Understanding SSR helps you balance freshness with speed depending on your app's needs.

5

Intermediate

Client-side Rendering Explained

Concept: Client-side Rendering builds the page in the browser after the initial load, often used for interactive parts.

In Client-side Rendering, the server sends minimal HTML and JavaScript to the browser. The browser then runs the React code to build the page. This can delay content visibility but allows dynamic updates without reloading.

Result

Pages can update dynamically but may show a blank screen initially.

Knowing CSR's tradeoffs helps you decide when to use it for interactivity versus initial load speed.

6

Advanced

Choosing the Right Rendering Strategy

🤔Before reading on: do you think faster loading always means better user experience? Commit to your answer.

Concept: Choosing a rendering strategy depends on your app's content type, update frequency, and user needs.

Static Generation is best for mostly unchanging pages like blogs. Server-side Rendering suits pages needing fresh data like dashboards. Client-side Rendering fits highly interactive parts like forms. Sometimes, combining these strategies in one app gives the best results.

Result

You can match rendering strategies to different page needs for better performance and UX.

Understanding that speed alone isn't enough helps you design smarter apps that balance freshness and interactivity.

7

Expert

Incremental Static Regeneration Deep Dive

🤔Quick: does Incremental Static Regeneration rebuild pages on every request or only some? Commit to your answer.

Concept: Incremental Static Regeneration (ISR) lets you update static pages after build time without rebuilding the whole site.

ISR allows Next.js to serve static pages but regenerate them in the background when data changes. This means users get fast pages that stay fresh without full rebuilds. It combines the speed of static with the freshness of server rendering.

Result

Pages stay fast and up-to-date automatically, improving user experience and developer workflow.

Knowing ISR reveals how Next.js innovates to solve the static vs dynamic content tradeoff elegantly.

Under the Hood

Next.js uses Node.js on the server to run React code and generate HTML. For Static Generation, it runs this once at build time and saves the output. For Server-side Rendering, it runs on every request. Client-side Rendering sends JavaScript to the browser, which runs React to build the page. ISR uses a cache with timers to regenerate pages in the background.

Why designed this way?

Next.js was designed to combine React's flexibility with fast, SEO-friendly pages. Static Generation was chosen for speed and caching benefits. Server-side Rendering was kept for dynamic needs. ISR was introduced to overcome the limits of static sites needing frequent updates without slowing down the whole app.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Build Time  │──────▶│ Static Files  │──────▶│   User Browser│
│ (Static Gen)  │       │ (HTML/Assets) │       │ (Fast Load)   │
└───────────────┘       └───────────────┘       └───────────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User Request  │──────▶│ Server Render │──────▶│ User Browser  │
│ (SSR)         │       │ (HTML Gen)    │       │ (Fresh Page)  │
└───────────────┘       └───────────────┘       └───────────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ User Browser  │◀──────│ Client Render │◀──────│ JavaScript    │
│ (Initial Load)│       │ (React Build) │       │ (Dynamic UI)  │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Static Generation always mean pages never update unless rebuilt? Commit to yes or no.

Common Belief: Static Generation pages are fixed forever once built and cannot update without a full rebuild.

Reality: With Incremental Static Regeneration, static pages can update automatically in the background without rebuilding the entire site.

Why it matters: Believing static pages never update leads to avoiding Static Generation even when it could provide fast, fresh pages.

Quick: Is Server-side Rendering always slower than Static Generation? Commit to yes or no.

Common Belief: Server-side Rendering is always slower because it builds pages on every request.

Reality: While SSR can be slower, caching and efficient code can make it fast enough for many apps, and it ensures fresh data.

Why it matters: Thinking SSR is always slow may cause developers to avoid it even when fresh data is critical.

Quick: Does Client-side Rendering mean the server does no work at all? Commit to yes or no.

Common Belief: Client-side Rendering means the server only sends empty pages and does no rendering.

Reality: The server still sends initial HTML and JavaScript bundles; the browser then builds the UI, but the server prepares the assets.

Why it matters: Misunderstanding this can lead to inefficient asset loading and poor performance.

Quick: Can you mix rendering strategies on different pages in Next.js? Commit to yes or no.

Common Belief: You must choose one rendering strategy for the entire Next.js app.

Reality: Next.js allows mixing strategies per page, enabling hybrid apps that optimize speed and freshness per page.

Why it matters: Believing you must pick one strategy limits app design and performance optimization.

Expert Zone

1

ISR's regeneration happens asynchronously and does not block user requests, which means users always get a page immediately, even if it's slightly stale.

2

Server-side Rendering can be combined with caching layers like CDN or edge functions to reduce latency and server load.

3

Client-side Rendering can cause SEO challenges if not paired with pre-rendering, requiring careful planning for discoverability.

When NOT to use

Avoid Static Generation for highly personalized or real-time data pages; use Server-side Rendering or Client-side Rendering instead. Avoid SSR for pages that can be cached heavily to reduce server costs. For very dynamic single-page apps, consider full Client-side Rendering frameworks.

Production Patterns

Real-world Next.js apps often use Static Generation for marketing pages, SSR for user dashboards, and Client-side Rendering for interactive widgets. ISR is used for blogs or e-commerce product pages that update frequently but need fast load times.

Connections

Content Delivery Networks (CDNs)

Rendering strategies often rely on CDNs to cache and deliver static or server-rendered pages quickly.

Understanding CDNs helps grasp how static and ISR pages achieve fast global delivery.

Database Caching

Server-side Rendering depends on fresh data, which can be optimized by caching database queries to reduce response time.

Knowing caching strategies improves SSR performance and user experience.

Cooking and Meal Prep

Rendering strategies mirror meal preparation timing: pre-cooked meals (static), made-to-order dishes (SSR), and finishing touches at the table (client-side).

This cross-domain view clarifies tradeoffs between speed, freshness, and flexibility.

Common Pitfalls

#1 Using Static Generation for pages that need real-time data updates.

Wrong approach:

export async function getStaticProps() {
const data = await fetch('https://api.example.com/live-data');
return { props: { data } };
}
// This builds once and never updates until rebuild

Correct approach:

export async function getServerSideProps() {
const data = await fetch('https://api.example.com/live-data');
return { props: { data } };
}
// This fetches fresh data on every request

Root cause:

Misunderstanding that Static Generation does not update data after build time.

#2 Relying solely on Client-side Rendering for SEO-critical pages.

Wrong approach:

function Page() {
const [data, setData] = React.useState(null);
React.useEffect(() => {
fetch('/api/data').then(res => res.json()).then(setData);
}, []);
return {data ? data.text : 'Loading...'};
}
// No pre-rendered content for crawlers

Correct approach:

export async function getStaticProps() {
const data = await fetch('/api/data').then(res => res.json());
return { props: { data } };
}
function Page({ data }) {
return {data.text};
}
// Pre-rendered content for SEO

Root cause:

Not realizing that client-side rendering delays content visibility to search engines.

#3 Forgetting to handle fallback behavior in ISR pages.

Wrong approach:

export async function getStaticPaths() {
return { paths: [], fallback: false };
}
// No fallback means missing pages return 404

Correct approach:

export async function getStaticPaths() {
return { paths: [], fallback: 'blocking' };
}
// Allows on-demand page generation

Root cause:

Not understanding how ISR fallback options affect page availability.

Key Takeaways

Rendering strategy in Next.js controls when and how pages are built, affecting speed and freshness.

Static Generation offers fast load times by pre-building pages but needs rebuilding to update content.

Server-side Rendering builds pages on each request, ensuring fresh data but with slower response times.

Client-side Rendering builds pages in the browser, enabling dynamic interactivity but can delay initial content.

Incremental Static Regeneration combines static speed with dynamic updates, solving many real-world challenges.

Practice

1. In Next.js, why does choosing the right rendering strategy matter for your website?

easy

A. It decides which fonts are used on the page.

B. It changes the color scheme of the website automatically.

C. It controls the size of images on the page.

D. It affects how fast the page loads and how fresh the content is.

Solution

1. Step 1: Understand rendering strategy impact

   Rendering strategy determines when and how page content is created and delivered to users.

2. Step 2: Connect rendering to performance and freshness

   Choosing the right strategy affects page load speed and how up-to-date the content appears, which is important for user experience and SEO.

3. Final Answer:

   It affects how fast the page loads and how fresh the content is. -> Option D

4. Quick Check:

   Rendering strategy = speed and freshness [OK]

Hint: Rendering strategy controls speed and content freshness [OK]

Common Mistakes:

• Thinking rendering changes colors or fonts
• Confusing rendering with styling or image size
• Assuming rendering affects only visuals, not performance

2. Which Next.js page export correctly sets a page to use Static Site Generation (SSG)?

easy

A. export default function Page() { return Hello }

B. export const getServerSideProps = async () => { return { props: {} } }

C. export const getStaticProps = async () => { return { props: {} } }

D. export const getInitialProps = async () => { return { props: {} } }

Solution

1. Step 1: Identify SSG method in Next.js

   Static Site Generation uses getStaticProps to fetch data at build time.

2. Step 2: Match export to SSG

   Only getStaticProps triggers SSG; others are for server-side or legacy methods.

3. Final Answer:

   export const getStaticProps = async () => { return { props: {} } } -> Option C

4. Quick Check:

   SSG = getStaticProps [OK]

Hint: SSG uses getStaticProps export [OK]

Common Mistakes:

• Confusing getServerSideProps with SSG
• Using getInitialProps which is legacy
• Not exporting any data fetching function

3. Given this Next.js page code, what will the user see when visiting the page?

export async function getServerSideProps() {
  return { props: { time: new Date().toISOString() } };
}

export default function Page({ time }) {
  return 
Current time: {time}
;
}

medium

A. The current server time updated on every request.

B. The time when the site was built, never changes.

C. An error because getServerSideProps cannot return props.

D. A blank page because time is undefined.

Solution

1. Step 1: Understand getServerSideProps behavior

   This function runs on every request, fetching fresh data each time.

2. Step 2: Analyze returned props usage

   The page receives the current server time as a prop and displays it inside the div.

3. Final Answer:

   The current server time updated on every request. -> Option A

4. Quick Check:

   getServerSideProps = fresh data each request [OK]

Hint: getServerSideProps runs every request, shows fresh data [OK]

Common Mistakes:

• Thinking it shows build time (that's SSG)
• Assuming getServerSideProps causes errors
• Believing props are undefined without checking code

4. This Next.js page uses Static Site Generation but the data is not updating after deployment. What is the likely fix?

export async function getStaticProps() {
  const data = await fetch('https://api.example.com/data').then(res => res.json());
  return { props: { data } };
}

export default function Page({ data }) {
  return 
{data.message}
;
}

medium

A. Add revalidate property to enable Incremental Static Regeneration.

B. Change getStaticProps to getServerSideProps to fetch on every request.

C. Remove the fetch call to avoid stale data.

D. Wrap the component in React.memo to force updates.

Solution

1. Step 1: Identify SSG data freshness issue

   Static Site Generation builds pages once at build time, so data stays static unless re-built.

2. Step 2: Use revalidate for periodic updates

   Adding revalidate enables Incremental Static Regeneration, refreshing data after set seconds.

3. Final Answer:

   Add revalidate property to enable Incremental Static Regeneration. -> Option A

4. Quick Check:

   SSG + revalidate = fresh static pages [OK]

Hint: Use revalidate in getStaticProps for fresh static data [OK]

Common Mistakes:

• Switching to getServerSideProps unnecessarily
• Removing fetch which breaks data loading
• Using React.memo which doesn't affect data fetching

5. You want a Next.js page that shows user profile data that updates every 10 seconds but also loads fast initially. Which rendering strategy best fits this need?

hard

A. Use Server-side Rendering with getServerSideProps to fetch data on every request.

B. Use Static Site Generation with revalidate: 10 to update every 10 seconds.

C. Use Client-side Rendering only with useEffect to fetch data after page loads.

D. Use Static Site Generation without revalidate for fastest load.

Solution

1. Step 1: Understand the need for fast initial load and frequent updates

   Static Site Generation gives fast load by pre-building pages; revalidate allows periodic updates.

2. Step 2: Compare options for update frequency and speed

   Using revalidate: 10 updates the page every 10 seconds without slowing initial load, unlike server-side rendering which runs every request.

3. Final Answer:

   Use Static Site Generation with revalidate: 10 to update every 10 seconds. -> Option B

4. Quick Check:

   SSG + revalidate = fast + fresh [OK]

Hint: SSG with revalidate balances speed and freshness [OK]

Common Mistakes:

• Choosing server-side rendering which slows initial load
• Using client-side fetching which delays content display
• Ignoring revalidate option for periodic updates