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.