Static rendering (default) in NextJS - Deep Dive

Overview - Static rendering (default)

What is it?

Static rendering is a way Next.js builds web pages ahead of time, before anyone visits them. It creates HTML files during the build process that stay the same for every user. This means the page loads very fast because the server just sends the ready-made HTML. It is the default way Next.js generates pages unless you specify otherwise.

Why it matters

Without static rendering, every page would be built on the fly when someone visits, which can slow down the website and make users wait. Static rendering solves this by preparing pages in advance, making websites faster and more reliable. This improves user experience and helps websites handle many visitors at once without slowing down.

Where it fits

Before learning static rendering, you should understand basic React components and how Next.js pages work. After mastering static rendering, you can learn about server-side rendering and client-side rendering to handle dynamic content and user-specific data.

Mental Model

Core Idea

Static rendering means building the full page once during the build, then serving the same fast, ready page to every visitor.

Think of it like...

It's like baking a batch of cookies before guests arrive, so when they come, you just hand them a cookie instead of baking one from scratch each time.

Build Time
  │
  ▼
[Generate HTML files]
  │
  ▼
Run Time (User visits)
  │
  ▼
[Serve pre-built HTML instantly]

Build-Up - 6 Steps

1

Foundation

What is Static Rendering in Next.js

Concept: Static rendering creates HTML pages at build time, not on each user request.

Next.js by default pre-builds pages into static HTML during the build process. This means when a user visits, the server sends this pre-made HTML immediately without extra processing.

Result

Pages load very fast because the server only sends ready HTML files.

Understanding that static rendering happens before users visit helps grasp why pages load quickly and use less server power.

2

Foundation

How Next.js Builds Static Pages

Concept: Next.js runs your React components once during build to create static HTML files.

During the build, Next.js executes your page components and saves the output as HTML files. These files include all the content and structure of the page, ready to be sent to browsers.

Result

The website has a folder of static HTML files representing each page.

Knowing that React components run at build time clarifies how dynamic React code becomes static HTML.

3

Intermediate

Static Props for Data at Build Time

🤔Before reading on: do you think static pages can include data that changes often? Commit to yes or no.

Concept: Next.js lets you fetch data at build time using getStaticProps to include it in static pages.

You can export a function called getStaticProps in your page. Next.js runs this function at build time to get data, then uses it to build the static HTML. This data stays fixed until the next build.

Result

Static pages can show data fetched once during build, like blog posts or product lists.

Understanding getStaticProps shows how static pages can include real data, but only updated when you rebuild.

4

Intermediate

Static Paths for Dynamic Routes

🤔Before reading on: do you think Next.js can statically build pages for dynamic URLs like /posts/1? Commit to yes or no.

Concept: Next.js uses getStaticPaths to tell which dynamic pages to build at build time.

For pages with dynamic routes (like [id].js), you export getStaticPaths to list all possible paths. Next.js builds a static HTML page for each path during the build.

Result

Dynamic routes become static pages for each specified path, improving speed and SEO.

Knowing getStaticPaths enables static generation of many dynamic pages, combining flexibility with performance.

5

Advanced

Incremental Static Regeneration (ISR)

🤔Before reading on: do you think static pages can update after build without rebuilding the whole site? Commit to yes or no.

Concept: ISR lets Next.js update static pages after build by regenerating them in the background on demand.

By adding a revalidate time in getStaticProps, Next.js serves the static page but regenerates it in the background after the set time. This means pages stay fresh without full rebuilds.

Result

Static pages can update automatically over time, combining speed with fresh content.

Understanding ISR reveals how static rendering adapts to changing data without losing performance benefits.

6

Expert

Trade-offs and Limitations of Static Rendering

🤔Before reading on: do you think static rendering works well for user-specific content? Commit to yes or no.

Concept: Static rendering is fast but not suitable for content that changes per user or very frequently.

Static pages are the same for all users until rebuilt or regenerated. For personalized or real-time data, server-side or client-side rendering is better. Also, very large sites may face long build times.

Result

Knowing when static rendering fits helps choose the right rendering method for each page.

Recognizing static rendering limits prevents performance or user experience issues in complex apps.

Under the Hood

Next.js runs React components and data-fetching functions like getStaticProps and getStaticPaths during the build process. It converts the React output into plain HTML files saved on disk. When a user requests a page, the server quickly serves these static HTML files without running React code or fetching data again. For ISR, Next.js tracks the revalidate time and regenerates pages in the background, replacing old static files with new ones.

Why designed this way?

Static rendering was designed to improve website speed and scalability by pre-building pages. Before frameworks like Next.js, developers had to manually generate static sites or rely on slower server rendering. Next.js automates this process, combining React's power with static site benefits. ISR was added later to solve the problem of stale content without sacrificing performance.

Build Process
┌─────────────────────────────┐
│ Run React components & data │
│ fetching functions          │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Generate static HTML files   │
└──────────────┬──────────────┘
               │
               ▼
Runtime (User Request)
┌─────────────────────────────┐
│ Serve pre-built HTML files   │
│ No React or data fetching    │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does static rendering mean the page never changes after build? Commit to yes or no.

Common Belief: Static rendering means the page is fixed forever and cannot update without a full rebuild.

Reality: With Incremental Static Regeneration, static pages can update automatically after a set time without rebuilding the whole site.

Why it matters: Believing static pages never update leads to missing out on ISR benefits and building unnecessarily complex solutions.

Quick: Can static rendering handle user-specific content like logged-in user data? Commit to yes or no.

Common Belief: Static rendering can be used for any content, including personalized user data.

Reality: Static rendering creates the same page for all users; it cannot show user-specific content without client-side code or server rendering.

Why it matters: Using static rendering for personalized content causes wrong or stale data to show, harming user experience.

Quick: Does static rendering always make build times short? Commit to yes or no.

Common Belief: Static rendering always results in fast builds regardless of site size.

Reality: Large sites with many pages can have long build times because every page is generated at build time.

Why it matters: Ignoring build time impact can cause slow deployments and developer frustration.

Quick: Is static rendering the same as server-side rendering? Commit to yes or no.

Common Belief: Static rendering and server-side rendering are the same because both generate HTML.

Reality: Static rendering builds pages once at build time; server-side rendering builds pages on every user request.

Why it matters: Confusing these leads to wrong expectations about performance and data freshness.

Expert Zone

1

Static rendering with ISR can cause a brief moment where users see stale content before regeneration completes, known as stale-while-revalidate behavior.

2

Using fallback: 'blocking' in getStaticPaths delays the first request for a new path until the page is generated, improving SEO but increasing initial load time.

3

Static rendering works best when combined with client-side hydration to add interactivity after the static HTML loads.

When NOT to use

Static rendering is not suitable for pages requiring real-time data, user-specific content, or very frequent updates. In those cases, use server-side rendering (getServerSideProps) or client-side rendering with React hooks and APIs.

Production Patterns

In production, static rendering is often used for marketing pages, blogs, documentation, and product catalogs. ISR is used to keep content fresh without full rebuilds. Developers combine static rendering with client-side fetching for personalization and dynamic features.

Connections

Server-side rendering

Opposite approach to static rendering; builds pages on each request instead of build time.

Understanding server-side rendering clarifies when static rendering is best and when dynamic content needs real-time generation.

Content Delivery Networks (CDNs)

Static pages are often cached and served globally via CDNs for fast delivery.

Knowing how CDNs work helps understand why static rendering improves load speed worldwide.

Manufacturing assembly lines

Static rendering is like pre-assembling products before customers order, while server-side rendering is like custom-building on demand.

This connection shows how pre-building saves time and resources, a principle common in many fields.

Common Pitfalls

#1 Trying to show user-specific data directly in static pages.

Wrong approach:

export async function getStaticProps() {
const user = await fetchUser(); // user changes per visitor
return { props: { user } };
}

export default function Page({ user }) {
return Hello, {user.name};
}

Correct approach:

import React from 'react';

export async function getStaticProps() {
return { props: {} };
}

export default function Page() {
const [user, setUser] = React.useState(null);
React.useEffect(() => {
fetchUser().then(setUser);
}, []);
if (!user) return Loading...;
return Hello, {user.name};
}

Root cause:

Misunderstanding that static props run once at build time and cannot access per-user data.

#2 Not specifying getStaticPaths for dynamic routes, causing build errors or missing pages.

Wrong approach:

export default function Post({ post }) {
return {post.title};
}

export async function getStaticProps({ params }) {
const post = await fetchPost(params.id);
return { props: { post } };
}

Correct approach:

export async function getStaticPaths() {
const posts = await fetchAllPosts();
const paths = posts.map(post => ({ params: { id: post.id.toString() } }));
return { paths, fallback: false };
}

Root cause:

Forgetting that dynamic static pages need explicit paths to be generated at build time.

#3 Setting revalidate to 0 or a very low number causing excessive rebuilds.

Wrong approach:

export async function getStaticProps() {
return { props: { data }, revalidate: 1 };
}

Correct approach:

export async function getStaticProps() {
return { props: { data }, revalidate: 60 };
}

Root cause:

Not understanding that very frequent regeneration can overload the server and negate static benefits.

Key Takeaways

Static rendering in Next.js builds pages once at build time, delivering fast, ready HTML to users.

Using getStaticProps and getStaticPaths lets you include data and dynamic routes in static pages.

Incremental Static Regeneration updates static pages after build, keeping content fresh without full rebuilds.

Static rendering is best for content that doesn't change per user or very often; use other methods for dynamic or personalized data.

Understanding static rendering helps optimize website speed, scalability, and user experience.

Practice

1. What does static rendering in Next.js do by default?

easy

A. Builds pages once at build time for fast loading

B. Fetches data on every user request

C. Renders pages only on the client side

D. Updates pages dynamically without rebuilding

Solution

1. Step 1: Understand static rendering concept

   Static rendering means pages are generated once during the build process, not on each request.

2. Step 2: Compare options with static rendering

   Only Builds pages once at build time for fast loading describes building pages once at build time, which matches static rendering.

3. Final Answer:

   Builds pages once at build time for fast loading -> Option A

4. Quick Check:

   Static rendering = build time page generation [OK]

Hint: Static rendering means build once, serve many times [OK]

Common Mistakes:

• Confusing static rendering with server-side rendering
• Thinking pages update on every request
• Assuming static rendering is client-side only

2. Which of the following is the correct way to export a statically rendered page in Next.js?

easy

A. export default class Page extends React.Component {}

B. export async function getServerSideProps() { return { props: {} } }

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

D. export function getStaticProps() { return { props: {} } }

Solution

1. Step 1: Identify static rendering export style

   Static rendering by default requires exporting a React function component without server-side data fetching.

2. Step 2: Analyze options

   export default function Page() { return
   Hello } exports a simple functional component, which Next.js statically renders by default. export async function getServerSideProps() { return { props: {} } } uses server-side props, which disables static rendering. export default class Page extends React.Component {} uses a class component, which is discouraged. export function getStaticProps() { return { props: {} } } exports getStaticProps but not default component, so incomplete.

3. Final Answer:

   export default function Page() { return <div>Hello</div> } -> Option C

4. Quick Check:

   Default export function = static page [OK]

Hint: Static pages export default function only [OK]

Common Mistakes:

• Using getServerSideProps disables static rendering
• Using class components instead of functions
• Not exporting a default component

3. Given this Next.js page code, what will be the output when visiting the page?

export default function Page() {
  return <h1>Welcome to Next.js!</h1>
}

medium

A. A page showing 'Welcome to Next.js!' rendered statically

B. A server error because no data fetching is defined

C. A blank page because no getStaticProps is used

D. A client-side rendered page only

Solution

1. Step 1: Check the component structure

   The component is a simple function returning an <h1> element with text.

2. Step 2: Understand default rendering behavior

   Without data fetching methods, Next.js statically renders this page at build time.

3. Final Answer:

   A page showing 'Welcome to Next.js!' rendered statically -> Option A

4. Quick Check:

   Simple function component = static render [OK]

Hint: No data fetching means static render by default [OK]

Common Mistakes:

• Expecting runtime errors without data fetching
• Thinking getStaticProps is always required
• Confusing static with client-side rendering

4. Identify the error in this Next.js page that prevents static rendering:

export default function Page() {
  const data = fetch('https://api.example.com/data')
  return <div>{data.title}</div>
}

medium

A. fetch is used inside the component without async/await

B. Static rendering requires getStaticProps for data fetching

C. Using fetch disables static rendering automatically

D. The component must be a class to fetch data

Solution

1. Step 1: Analyze data fetching in component

   The component calls fetch directly inside the function without async/await or data fetching methods.

2. Step 2: Recall static rendering data rules

   Static rendering requires data fetching outside the component using getStaticProps to fetch data at build time.

3. Final Answer:

   Static rendering requires getStaticProps for data fetching -> Option B

4. Quick Check:

   Data fetching for static = getStaticProps [OK]

Hint: Use getStaticProps for build-time data fetch [OK]

Common Mistakes:

• Calling fetch inside component without async
• Assuming fetch disables static rendering
• Thinking class components are required

5. You want to build a blog with mostly fixed posts but occasionally update some posts. How should you use static rendering in Next.js to handle this efficiently?

hard

A. Use client-side rendering to fetch posts on every visit

B. Use only server-side rendering for all posts

C. Build static pages once and never update them

D. Use static rendering with getStaticProps and enable incremental static regeneration

Solution

1. Step 1: Understand blog content update needs

   Most posts are fixed, but some need occasional updates without full rebuilds.

2. Step 2: Identify Next.js feature for this case

   Incremental Static Regeneration (ISR) allows static pages to update after build time on demand.

3. Step 3: Match option with ISR usage

   Use static rendering with getStaticProps and enable incremental static regeneration uses getStaticProps with ISR, enabling static rendering plus updates efficiently.

4. Final Answer:

   Use static rendering with getStaticProps and enable incremental static regeneration -> Option D

5. Quick Check:

   ISR + getStaticProps = static + updates [OK]

Hint: Use ISR to update static pages without full rebuilds [OK]

Common Mistakes:

• Choosing server-side rendering for mostly fixed content
• Ignoring ISR for occasional updates
• Assuming static pages cannot update after build