Revalidation strategies (time-based) in NextJS - Deep Dive

Overview - Revalidation strategies (time-based)

What is it?

Revalidation strategies in Next.js control how often a page or data is refreshed after it is first generated. Time-based revalidation means the page updates automatically after a set time interval. This helps keep content fresh without rebuilding on every request. It balances speed and up-to-date information for users.

Why it matters

Without revalidation, pages might show outdated content or slow down by rebuilding too often. Time-based revalidation solves this by updating pages at regular intervals, so users see fresh data without waiting. This improves user experience and reduces server load, making websites faster and more reliable.

Where it fits

Before learning revalidation, you should understand static site generation and server-side rendering in Next.js. After mastering revalidation, you can explore incremental static regeneration, on-demand revalidation, and caching strategies to optimize performance further.

Mental Model

Core Idea

Time-based revalidation automatically refreshes static pages after a set time to keep content fresh without rebuilding on every request.

Think of it like...

It's like a bakery that bakes a batch of bread every hour. Customers get fresh bread without waiting for each loaf to be made individually.

┌───────────────────────────────┐
│ Initial Page Build (Static)    │
└───────────────┬───────────────┘
                │
                ▼
      ┌─────────────────────┐
      │ Serve Cached Page   │
      └─────────┬───────────┘
                │
     Time passes (e.g., 60s)
                │
                ▼
      ┌─────────────────────┐
      │ Rebuild Page in     │
      │ Background          │
      └─────────┬───────────┘
                │
                ▼
      ┌─────────────────────┐
      │ Serve Updated Page  │
      └─────────────────────┘

Build-Up - 7 Steps

1

Foundation

Static Generation Basics

Concept: Understand how Next.js creates static pages at build time.

Next.js can generate pages once when you build your app. These pages are saved as static files and served quickly to users. This is called Static Site Generation (SSG). It makes pages load fast but the content stays the same until you rebuild the app.

Result

Pages load very fast because they are pre-built and served as files.

Understanding static generation is key because time-based revalidation builds on this by updating static pages after the initial build.

2

Foundation

Why Static Pages Need Updating

Concept: Static pages can become outdated if data changes after build time.

Imagine a blog page built statically. If you add a new post, the static page won't show it until you rebuild. This delay can confuse users or show old info. So, static pages need a way to update without rebuilding the whole app manually.

Result

Static pages can show stale content if not updated.

Knowing this problem motivates the need for revalidation strategies to keep static content fresh.

3

Intermediate

Time-Based Revalidation Concept

Concept: Next.js can automatically rebuild static pages after a set time interval.

You can tell Next.js to regenerate a page in the background after a certain number of seconds using the 'revalidate' property in getStaticProps. When a user visits after that time, Next.js serves the old page but triggers a rebuild. The next visitor gets the updated page.

Result

Pages update automatically at intervals without slowing down users.

This approach balances fast loading with fresh content by rebuilding only when needed.

4

Intermediate

Implementing Revalidation in Next.js

🤔Before reading on: Do you think revalidation happens before or after serving the page? Commit to your answer.

Concept: Learn how to add the 'revalidate' field in getStaticProps to enable time-based revalidation.

In your page's getStaticProps function, return an object with a 'revalidate' key set to the number of seconds between rebuilds. For example: export async function getStaticProps() { const data = await fetchData(); return { props: { data }, revalidate: 60, // rebuild page every 60 seconds }; } This tells Next.js to serve the static page immediately and rebuild it in the background if 60 seconds have passed since the last build.

Result

The page updates every 60 seconds without blocking users.

Knowing that revalidation happens after serving the page explains why users never wait for rebuilds, improving experience.

5

Intermediate

How Revalidation Affects User Experience

🤔Before reading on: Will users see stale content during revalidation or always fresh content? Commit to your answer.

Concept: Understand the user impact during the revalidation process.

When a page is due for revalidation, the first user after the interval still gets the old page instantly. Meanwhile, Next.js rebuilds the page in the background. The next user gets the fresh page. This means users never wait for rebuilding but might see slightly outdated content briefly.

Result

Users get fast responses with minimal stale content exposure.

Understanding this tradeoff helps set expectations about content freshness and performance.

6

Advanced

Revalidation and Caching Layers

🤔Before reading on: Does Next.js revalidate before or after CDN caches? Commit to your answer.

Concept: Explore how time-based revalidation interacts with CDN and browser caches.

Next.js revalidation happens on the server side. If you use a CDN, it may cache the static page too. The CDN cache TTL should align with your revalidate time to avoid serving stale content longer than intended. Otherwise, users might see outdated pages from the CDN even after Next.js rebuilt them.

Result

Proper cache settings ensure users get fresh content consistently.

Knowing how CDN caching layers affect revalidation prevents confusing stale content issues in production.

7

Expert

Limitations and Edge Cases of Time-Based Revalidation

🤔Before reading on: Can time-based revalidation guarantee zero stale content? Commit to your answer.

Concept: Understand the boundaries and unexpected behaviors of time-based revalidation.

Time-based revalidation cannot guarantee zero stale content because the first user after the interval still gets the old page. Also, if your rebuild process is slow or fails, users might see outdated or broken pages longer. For critical data, on-demand revalidation or server-side rendering might be better. Additionally, revalidation intervals should be chosen carefully to balance freshness and server load.

Result

Recognizing these limits helps choose the right strategy for your app's needs.

Knowing these edge cases prevents over-reliance on time-based revalidation for all scenarios.

Under the Hood

Next.js stores static pages as files after the initial build. When a page with time-based revalidation is requested, Next.js checks the timestamp of the last build. If the set interval has passed, it serves the existing static page immediately and triggers a background rebuild. The rebuilt page replaces the old static file for future requests. This process uses serverless functions or Node.js server capabilities depending on deployment.

Why designed this way?

This design balances performance and freshness by avoiding rebuild delays on user requests. It leverages static generation speed while allowing periodic updates. Alternatives like rebuilding on every request would slow down responses. Fully dynamic rendering would increase server load. Time-based revalidation offers a middle ground optimized for many use cases.

┌───────────────┐       ┌─────────────────────┐
│ User Request  │──────▶│ Serve Cached Static  │
│               │       │ Page Immediately     │
└───────┬───────┘       └─────────┬───────────┘
        │                           │
        │                           ▼
        │                 ┌─────────────────────┐
        │                 │ Check Revalidate Time│
        │                 └─────────┬───────────┘
        │                           │
        │           If interval passed│
        │                           ▼
        │                 ┌─────────────────────┐
        │                 │ Trigger Background   │
        │                 │ Rebuild of Page      │
        │                 └─────────┬───────────┘
        │                           │
        │                           ▼
        │                 ┌─────────────────────┐
        └─────────────────│ Replace Static Page  │
                          └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does time-based revalidation rebuild the page before serving it to the user? Commit to yes or no.

Common Belief: Time-based revalidation rebuilds the page before serving it, so users always get fresh content.

Reality: Next.js serves the existing static page immediately and rebuilds the page in the background after the revalidation interval.

Why it matters: Believing this causes confusion about why users sometimes see stale content and leads to wrong expectations about page load times.

Quick: Do you think setting revalidate to 0 disables caching? Commit to yes or no.

Common Belief: Setting revalidate to 0 means the page is never cached and always rebuilt on every request.

Reality: In Next.js, revalidate must be a positive integer. Setting it to 0 disables incremental static regeneration and falls back to static generation without revalidation.

Why it matters: Misunderstanding this can cause developers to expect dynamic behavior but get stale static pages instead.

Quick: Does time-based revalidation guarantee zero stale content? Commit to yes or no.

Common Belief: Time-based revalidation ensures users never see stale content.

Reality: The first user after the revalidation interval still sees the old page until the background rebuild completes.

Why it matters: Expecting zero stale content can lead to wrong choices for critical data that needs instant updates.

Quick: Does Next.js automatically handle CDN cache invalidation with revalidation? Commit to yes or no.

Common Belief: Next.js automatically clears CDN caches when a page is revalidated.

Reality: Next.js does not manage CDN cache invalidation; developers must configure CDN TTLs to align with revalidation intervals.

Why it matters: Ignoring CDN cache can cause users to see outdated content longer than intended, hurting freshness.

Expert Zone

1

Revalidation intervals should consider traffic patterns; high-traffic pages can use shorter intervals without much server strain.

2

Background rebuilds are atomic; the new page replaces the old only after successful build, preventing partial updates.

3

On-demand revalidation can complement time-based strategies for urgent content updates, triggered by external events.

When NOT to use

Avoid time-based revalidation for highly dynamic or user-specific content where instant freshness is critical. Use server-side rendering or client-side fetching instead. Also, if your rebuilds are slow or costly, consider on-demand revalidation or caching layers to reduce load.

Production Patterns

In production, teams combine time-based revalidation with CDN caching and on-demand revalidation APIs. They monitor rebuild times and errors to ensure smooth updates. Popular use cases include blogs, marketing pages, and product catalogs where data changes regularly but not instantly.

Connections

Caching Strategies

Builds-on and complements

Understanding caching helps optimize revalidation intervals and CDN settings to deliver fresh content efficiently.

Server-Side Rendering (SSR)

Alternative approach

Knowing SSR clarifies when to use dynamic rendering instead of static regeneration for real-time data needs.

Supply Chain Inventory Replenishment

Similar pattern of timed refresh

Just like inventory is restocked at intervals to balance supply and demand, time-based revalidation balances content freshness and performance.

Common Pitfalls

#1 Setting revalidate too low causing server overload

Wrong approach:

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

Correct approach:

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

Root cause:

Misunderstanding that very short intervals cause frequent rebuilds, increasing server load and slowing responses.

#2 Expecting instant content update after data change

Wrong approach:

Relying solely on revalidate without on-demand revalidation or SSR for critical updates.

Correct approach:

Use on-demand revalidation API or SSR for immediate content changes alongside time-based revalidation.

Root cause:

Not realizing that revalidation updates happen only after the interval and rebuild completion.

#3 Ignoring CDN cache settings causing stale content

Wrong approach:

Deploying with CDN TTL longer than revalidate interval without cache invalidation.

Correct approach:

Configure CDN TTL to match or be shorter than revalidate interval to ensure fresh content delivery.

Root cause:

Assuming Next.js handles CDN cache invalidation automatically.

Key Takeaways

Time-based revalidation in Next.js updates static pages automatically after a set interval, balancing speed and freshness.

It serves cached pages immediately and rebuilds in the background, so users never wait but might see slightly stale content briefly.

Properly setting revalidate intervals and aligning CDN caches is essential to avoid stale content and server overload.

Time-based revalidation is great for mostly static content but not suitable for highly dynamic or user-specific data.

Combining revalidation with on-demand updates and server-side rendering provides flexible strategies for real-world apps.

Practice

1. What does setting the revalidate property in getStaticProps do in Next.js?

easy

A. It tells Next.js to update the static page automatically after the specified seconds.

B. It disables static generation and forces server-side rendering.

C. It caches the page forever without any updates.

D. It triggers a client-side fetch to update the page content.

Solution

1. Step 1: Understand revalidate role in getStaticProps

   The revalidate property sets a time interval in seconds for Next.js to regenerate the static page in the background.

2. Step 2: Effect of setting revalidate

   After the specified time, Next.js updates the static page automatically without manual rebuilds or disabling static generation.

3. Final Answer:

   It tells Next.js to update the static page automatically after the specified seconds. -> Option A

4. Quick Check:

   Time-based revalidation = automatic page update [OK]

Hint: Remember: revalidate sets auto-update time in seconds [OK]

Common Mistakes:

• Thinking revalidate disables static generation
• Confusing revalidate with client-side fetching
• Assuming revalidate caches forever

2. Which of the following is the correct way to set a 10-second revalidation in getStaticProps?

easy

A. export async function getStaticProps() { return { props: {}, revalidate: null } }

B. export async function getStaticProps() { return { props: {}, revalidate: '10' } }

C. export async function getStaticProps() { return { props: {}, revalidate: true } }

D. export async function getStaticProps() { return { props: {}, revalidate: 10 } }

Solution

1. Step 1: Check the type of revalidate

   The revalidate value must be a number representing seconds.

2. Step 2: Validate each option's syntax

   export async function getStaticProps() { return { props: {}, revalidate: 10 } } uses a number 10 correctly. export async function getStaticProps() { return { props: {}, revalidate: '10' } } uses a string '10' which is invalid. The other options use boolean and null, which are incorrect types.

3. Final Answer:

   export async function getStaticProps() { return { props: {}, revalidate: 10 } } -> Option D

4. Quick Check:

   revalidate must be a number [OK]

Hint: Use a number for revalidate seconds, not string or boolean [OK]

Common Mistakes:

• Using string instead of number for revalidate
• Setting revalidate to true or null
• Forgetting to return revalidate inside the returned object

3. Given this code snippet in getStaticProps:

export async function getStaticProps() {
  return {
    props: { time: Date.now() },
    revalidate: 5
  }
}

What will happen if you visit the page multiple times within 3 seconds?

medium

A. The page will show the same time value for all visits within 3 seconds.

B. The page will update time on every visit regardless of time.

C. The page will throw an error because revalidate is too short.

D. The page will never update the time value.

Solution

1. Step 1: Understand revalidate timing

   The revalidate: 5 means Next.js regenerates the page at most every 5 seconds.

2. Step 2: Behavior within 3 seconds

   Visiting within 3 seconds means the cached page is served with the same time value because regeneration hasn't happened yet.

3. Final Answer:

   The page will show the same time value for all visits within 3 seconds. -> Option A

4. Quick Check:

   Revalidate interval controls update frequency [OK]

Hint: Page updates only after revalidate seconds pass [OK]

Common Mistakes:

• Expecting page to update on every visit
• Thinking revalidate causes errors if too small
• Assuming page never updates after first build

4. You set revalidate: 0 in getStaticProps. What is the problem with this code?

medium

A. It causes the page to never render.

B. It caches the page forever without updates.

C. It disables static generation and causes a build error.

D. It causes the page to regenerate on every request, similar to server-side rendering.

Solution

1. Step 1: Understand revalidate: 0 meaning

   Setting revalidate to 0 disables Incremental Static Regeneration (ISR). The page is generated at build time and cached forever without background regeneration.

2. Step 2: Effect on page behavior

   This results in no automatic updates, which is the problem if revalidation was intended, behaving like static generation without ISR.

3. Final Answer:

   It caches the page forever without updates. -> Option B

4. Quick Check:

   revalidate 0 = no ISR, cache forever [OK]

Hint: revalidate: 0 caches forever, no updates [OK]

Common Mistakes:

• Thinking revalidate: 0 regenerates on every request
• Believing it causes a build error
• Assuming it prevents the page from rendering

5. You want a page to update its static content every 60 seconds but only if the content has changed. Which Next.js feature combined with revalidate helps achieve this efficiently?

hard

A. Use getServerSideProps instead of getStaticProps.

B. Use revalidate: false to disable updates and manually rebuild.

C. Use revalidate: 60 with Incremental Static Regeneration (ISR) and conditional data fetching.

D. Set revalidate: 0 to regenerate on every request.

Solution

1. Step 1: Understand ISR with revalidate

   Incremental Static Regeneration (ISR) allows pages to update after a set time without full rebuilds.

2. Step 2: Combine with conditional data fetching

   Fetching data conditionally inside getStaticProps ensures updates only when content changes, saving resources.

3. Final Answer:

   Use revalidate: 60 with Incremental Static Regeneration (ISR) and conditional data fetching. -> Option C

4. Quick Check:

   ISR + revalidate = efficient timed updates [OK]

Hint: ISR with revalidate controls timed updates smartly [OK]

Common Mistakes:

• Using getServerSideProps which disables static caching
• Setting revalidate to false which is invalid
• Using revalidate 0 causing regen every request