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.