Next.js Caching Strategies

Explore the differences between static, incremental static regeneration, and server-side rendering caches in Next.js.

---

One of the big reasons why Next.js is so popular is how it balances performance and flexibility. Depending on the data needs of your application, you can fetch content at build time, at runtime, or do a mix of both. In this article, we’ll dive into three caching strategies in Next.js and look at when (and how) to use them.

1. Static Site Generation (SSG)
2. Incremental Static Regeneration (ISR)
3. Server-Side Rendering (SSR) Cache

---

1. Static Site Generation (SSG) Cache

The Basics of getStaticProps

With Static Site Generation (SSG), Next.js generates your pages as static HTML files at build time. It does this through a special function called getStaticProps.

// pages/index.js
export async function getStaticProps() {
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();

  return {
    props: { posts }, // props for the page
  };
}

export default function HomePage({ posts }) {
  return (
    <main>
      <h1>Latest Posts</h1>
      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.body}</p>
        </article>
      ))}
    </main>
  );
}

When you run npm run build, Next.js executes the getStaticProps function, fetches your posts, and generates a static HTML file that includes all the data you requested. Once the site is deployed, these pages are served “as is” to your visitors, which means:

• Faster Load Times: The pages are just static HTML, so they’re super quick to load.
• SEO Benefits: Search engines can easily index your fully rendered pages.

Best Use Cases for SSG

• Pages with Infrequent Updates: If your data doesn’t change often (think marketing pages, or static blog posts), SSG is a perfect fit.
• High-Traffic Content: Static files can be delivered by a CDN quickly, so even if your site has thousands or millions of visitors, the server load is minimal.
• Simplicity: If you want to keep your build pipeline straightforward and aren’t updating content on a tight schedule, SSG is easy to reason about.

Trade-Offs

• Build-Time Increases: If you have thousands of pages, building them all statically can be time-consuming.
• No Real-Time Content: Once your site is built, new data won’t appear until you trigger another rebuild (unless you incorporate some form of incremental approach—more on that next!).

---

2. Incremental Static Regeneration (ISR)

Revalidate: Keeping Static Content Fresh

Incremental Static Regeneration (ISR) is like SSG with a twist. It lets you update or “regenerate” static pages after the site is built, without manually rebuilding your entire site.

Here’s the key: getStaticProps can return a revalidate property indicating how many seconds Next.js should wait before regenerating the page.

// pages/blog/[slug].js
export async function getStaticProps({ params }) {
  const res = await fetch(`https://api.example.com/posts/${params.slug}`);
  const post = await res.json();

  return {
    props: { post },
    revalidate: 60, // re-generate the page every 60s
  };
}

export async function getStaticPaths() {
  // Generate paths for a few sample blog posts at build time
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();

  const paths = posts.map((p) => ({ params: { slug: p.slug } }));

  return {
    paths,
    fallback: 'blocking',
  };
}

export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
    </article>
  );
}

What happens here?

• When a user visits the page after 60 seconds have passed since the last regeneration, Next.js fetches fresh data in the background and replaces the old HTML.
• Meanwhile, site visitors continue to see the existing (cached) HTML until the new version is ready, which keeps the experience fast.

Best Use Cases for ISR

• Content that updates on a predictable or semi-regular schedule: For instance, product listings, blog posts that get occasional edits, or event calendars.
• Large Sites with Many Pages: You can statically generate a subset of critical pages and generate the rest “on-demand,” minimizing build times.
• Content Requiring Near Real-Time Updates: While it won’t be instant, ISR can get fresh data out there without forcing a full rebuild.

Trade-Offs

• Stale Data Windows: Users may see slightly older data until the page regenerates. For truly real-time scenarios, SSR or client-side fetching might be a better fit.
• Complex Build Logic: You’ll need to carefully manage paths and fallback behavior, especially if your content changes frequently or you have a large dynamic set of URLs.

---

3. Server-Side Rendering (SSR) Cache

A Quick Look at getServerSideProps

Server-Side Rendering (SSR) fetches data on each request rather than at build time. In Next.js, this is done via the getServerSideProps function.

// pages/dashboard.js
export async function getServerSideProps(context) {
  // possibly read cookies or session data for personalization
  const res = await fetch("https://api.example.com/user-data", {
    headers: { Authorization: `Bearer ${context.req.cookies.token}` },
  });
  const userData = await res.json();

  return {
    props: {
      userData,
    },
  };
}

export default function Dashboard({ userData }) {
  return (
    <section>
      <h1>Welcome, {userData.name}</h1>
      <p>Your account balance is {userData.balance}</p>
    </section>
  );
}

In SSR, each new request triggers your data fetching logic, so the server renders fresh HTML just for that user or moment in time. That’s great for highly dynamic or personalized content, but it also means there’s more load on the server.

Caching Strategies for SSR

When using SSR, you can implement custom caching layers, such as an in-memory cache (e.g., a simple JavaScript object or LRU cache) or a Redis store. The idea is to avoid hitting your data source on every single page load if the data doesn’t change that often.

Example: In-Memory Cache

// lib/cache.js
const NodeCache = require("node-cache");
const cache = new NodeCache({ stdTTL: 60 }); // TTL = 60 seconds

export default cache;

// pages/dashboard.js
import cache from "../lib/cache";

export async function getServerSideProps(context) {
  // check cache first
  let userData = cache.get("user-data");
  
  if (!userData) {
    const res = await fetch("https://api.example.com/user-data");
    userData = await res.json();
    cache.set("user-data", userData);
  }

  return {
    props: { userData },
  };
}

export default function Dashboard({ userData }) {
  // Render the personalized data
}

When is SSR the Right Choice?

• Highly Dynamic Content: If you need data that changes often—like stock prices, sports scores, or real-time analytics—SSR can ensure each visitor sees the newest data.
• Per-User Personalization: Because SSR is request-based, you can tailor the response to each user’s cookies, session data, or authentication tokens.
• Frequent Data Changes: If your content or data changes so often that even incremental static regeneration feels too stale, SSR might be your solution.

Trade-Offs

• Slower Response Times: Since each request triggers server logic, you lose the instant load benefits of static pages.
• Increased Server Load: More resources are used because every request involves rendering a page on the fly.
• Caching Complexity: Implementing custom caching requires more devops overhead and logic to ensure data stays fresh and consistent.

---

Conclusion

Next.js offers a flexible toolkit for data fetching and caching that can accommodate nearly any use case:

• SSG (getStaticProps): Pages are built upfront—perfect for content that’s basically set in stone or rarely updated.
• ISR (revalidate): You still get the performance of static files but with a dash of automatic regeneration. Great for content that changes occasionally but not in real time.
• SSR (getServerSideProps): Real-time or highly personalized content can be fetched on each request, potentially supercharged by your own caching layer for performance gains.

The best approach often depends on how frequently your data changes and how critical it is for users to see real-time updates. For many projects, a hybrid approach works wonders: some pages are entirely static, some use incremental regeneration, and a select few use SSR if personalization or real-time updates are needed.

As with most performance optimizations, test, measure, and refine. Keep an eye on build times, server costs, and user experience, then pick the caching strategy that best balances speed with simplicity for your unique application. Happy coding!